diff options
Diffstat (limited to 'docs/html/training')
71 files changed, 8160 insertions, 111 deletions
diff --git a/docs/html/training/accessibility/accessible-app.jd b/docs/html/training/accessibility/accessible-app.jd new file mode 100644 index 0000000..f4087b8 --- /dev/null +++ b/docs/html/training/accessibility/accessible-app.jd @@ -0,0 +1,194 @@ + +page.title=Developing Accessible Applications +parent.title=Implementing Accessibility +parent.link=index.html + +trainingnavtop=true +next.title=Developing an Accessibility Service +next.link=service.html + +@jd:body + + + + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#contentdesc">Add Content Descriptions</a></li> + <li><a href="#focus">Design for Focus Navigation</a></li> + <li><a href="#events">Fire Accessibility Events</a></li> + <li><a href="#testing">Test Your Application</a></li> +</ol> + +<!-- other docs (NOT javadocs) --> +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/topics/ui/accessibility/apps.html">Making + Applications Accessible</a></li> +</ul> + + +</div> +</div> + +<p>Android has several accessibility-focused features baked into the platform, +which make it easy to optimize your application for those with visual or +physical disabilities. However, it's not always obvious what the correct +optimizations are, or the easiest way to leverage the framework toward this +purpose. This lesson shows you how to implement the strategies and platform +features that make for a great accessibility-enabled Android application.</p> + +<h2 id="contentdesc">Add Content Descriptions</h2> +<p>A well-designed user interface (UI) often has elements that don't require an explicit +label to indicate their purpose to the user. A checkbox next to an item in a +task list application has a fairly obvious purpose, as does a trash can in a file +manager application. However, to your users with vision impairment, other UI +cues are needed.</p> + +<p>Fortunately, it's easy to add labels to UI elements in your application that +can be read out loud to your user by a speech-based accessibility service like <a + href="https://market.android.com/details?id=com.google.android.marvin.talkback">TalkBack</a>. +If you have a label that's likely not to change during the lifecycle of the +application (such as "Pause" or "Purchase"), you can add it via the XML layout, +by setting a UI element's <a + href="{@docRoot}reference/android/view.View#attr_android:contentDescription">android:contentDescription</a> attribute, like in this +example:</p> +<pre> +<Button + android:id=”@+id/pause_button” + android:src=”@drawable/pause” + android:contentDescription=”@string/pause”/> +</pre> + +<p>However, there are plenty of situations where it's desirable to base the content +description on some context, such as the state of a toggle button, or a piece +selectable data like a list item. To edit the content description at runtime, +use the {@link android.view.View#setContentDescription(CharSequence) +setContentDescription()} method, like this:</p> + +<pre> +String contentDescription = "Select " + strValues[position]; +label.setContentDescription(contentDescription); +</pre> + +<p>This addition to your code is the simplest accessibility improvement you can make to your +application, but one of the most useful. Try to add content descriptions +wherever there's useful information, but avoid the web-developer pitfall of +labelling <em>everything</em> with useless information. For instance, don't set +an application icon's content description to "app icon". That just increases +the noise a user needs to navigate in order to pull useful information from your +interface.</p> + +<p>Try it out! Download <a + href="https://market.android.com/details?id=com.google.android.marvin.talkback">TalkBack</a> +(an accessibility service published by Google) and enable it in <strong>Settings + > Accessibility > TalkBack</strong>. Then navigate around your own +application and listen for the audible cues provided by TalkBack.</p> + +<h2 id="focus">Design for Focus Navigation</h2> +<p>Your application should support more methods of navigation than the +touch screen alone. Many Android devices come with navigation hardware other +than the touchscreen, like a D-Pad, arrow keys, or a trackball. In addition, +later Android releases also support connecting external devices like keyboards +via USB or bluetooth.</p> + +<p>In order to enable this form of navigation, all navigational elements that +the user should be able to navigate to need to be set as focusable. This +modification can be +done at runtime using the +{@link android.view.View#setFocusable View.setFocusable()} method on that UI +control, or by setting the <a + href="{@docRoot}android.view.View#attr_android:focusable">{@code + android:focusable}</a> +attrubute in your XML layout files.</p> + +<p>Also, each UI control has 4 attributes, +<a href="{@docRoot}reference/android/view/View#attr_android:nextFocusUp">{@code + android:nextFocusUp}</a>, +<a + href="{@docRoot}reference/android/view/View#attr_android:nextFocusDown">{@code + android:nextFocusDown}</a>, +<a + href="{@docRoot}reference/android/view/View#attr_android:nextFocusLeft">{@code + android:nextFocusLeft}</a>, +and <a + href="{@docRoot}reference/android/view/View#attr_android:nextFocusRight">{@code + android:nextFocusRight}</a>, +which you can use to designate +the next view to receive focus when the user navigates in that direction. While +the platform determines navigation sequences automatically based on layout +proximity, you can use these attributes to override that sequence if it isn't +appropriate in your application. </p> + +<p>For instance, here's how you represent a button and label, both +focusable, such that pressing down takes you from the button to the text view, and +pressing up would take you back to the button.</p> + + +<pre> +<Button android:id="@+id/doSomething" + android:focusable="true" + android:nextFocusDown=”@id/label” + ... /> +<TextView android:id="@+id/label" + android:focusable=”true” + android:text="@string/labelText" + android:nextFocusUp=”@id/doSomething” + ... /> +</pre> + +<p>Verify that your application works intuitively in these situations. The +easiest way is to simply run your application in the Android emulator, and +navigate around the UI with the emulator's arrow keys, using the OK button as a +replacement for touch to select UI controls.</p> + +<h2 id="events">Fire Accessibility Events</h2> +<p>If you're using the view components in the Android framework, an +{@link android.view.accessibility.AccessibilityEvent} is created whenever you +select an item or change focus in your UI. These events are examined by the +accessibility service, enabling it to provide features like text-to-speech to +the user.</p> + +<p>If you write a custom view, make sure it fires events at the appropriate +times. Generate events by calling {@link +android.view.View#sendAccessibilityEvent(int)}, with a parameter representing +the type of event that occurred. A complete list of the event types currently +supported can be found in the {@link +android.view.accessibility.AccessibilityEvent} reference documentation. + +<p>As an example, if you want to extend an image view such that you can write +captions by typing on the keyboard when it has focus, it makes sense to fire an +{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_TEXT_CHANGED} +event, even though that's not normally built into image views. The code to +generate that event would look like this:</p> +<pre> +public void onTextChanged(String before, String after) { + ... + if (AccessibilityManager.getInstance(mContext).isEnabled()) { + sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED); + } + ... +} +</pre> + +<h2 id="testing">Test Your Application</h2> +<p>Be sure to test the accessibility functionality as you add it to your +application. In order to test the content descriptions and Accessibility +events, install and enable an accessibility service. One option is <a + href="https://play.google.com/store/details?id=com.google.android.marvin.talkback">Talkback</a>, +a free, open source screen reader available on Google Play. With the service +enabled, test all the navigation flows through your application and listen to +the spoken feedback.</p> + +<p>Also, attempt to navigate your application using a directional controller, +instead of the touch screen. You can use a physical device with a d-pad or +trackball if one is available. If not, use the Android emulator and it's +simulated keyboard controls.</p> + +<p>Between the service providing feedback and the directional navigation through +your application, you should get a sense of what your application is like to +navigate without any visual cues. Fix problem areas as they appear, and you'll +end up with with a more accessible Android application.</p> diff --git a/docs/html/training/accessibility/index.jd b/docs/html/training/accessibility/index.jd new file mode 100644 index 0000000..333f9f2 --- /dev/null +++ b/docs/html/training/accessibility/index.jd @@ -0,0 +1,55 @@ +page.title=Implementing Accessibility + +trainingnavtop=true +startpage=true +next.title=Developing Accessible Applications +next.link=accessible-app.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>Dependencies and prerequisites</h2> +<ul> + <li>Android 2.0 (API Level 5) or higher</li> +</ul> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/topics/ui/accessibility/index.html">Accessibility</a></li> +</ul> + +</div> +</div> + +<p>When it comes to reaching as wide a userbase as possible, it's important to +pay attention to accessibility in your Android application. Cues in your user +interface that may work for a majority of users, such as a visible change in +state when a button is pressed, can be less optimal if the user is visually +impaired.</p> + +<p>This class shows you how to make the most of the accessibility features +built into the Android framework. It covers how to optimize your app for +accessibility, leveraging platform features like focus navigation and content +descriptions. It also covers how to build accessibility services, that can +facilitate user interaction with <strong>any</strong> Android application, not +just your own.</p> + +<h2>Lessons</h2> + +<dl> + <dt><b><a href="accessible-app.html">Developing Accessible Applications</a></b></dt> + <dd>Learn to make your Android application accessible. Allow for easy + navigation with a keyboard or directional pad, set labels and fire events + that can be interpreted by an accessibility service to facilitate a smooth + user experience.</dd> + + <dt><b><a href="service.html">Developing Accessibility Services</a></b></dt> + <dd>Develop an accessibility service that listens for accessibility events, + mines those events for information like event type and content descriptions, + and uses that information to communicate with the user. The example will + use a text-to-speech engine to speak to the user.</dd> + +</dl> + diff --git a/docs/html/training/accessibility/service.jd b/docs/html/training/accessibility/service.jd new file mode 100644 index 0000000..f62506b --- /dev/null +++ b/docs/html/training/accessibility/service.jd @@ -0,0 +1,286 @@ + +page.title=Developing an Accessibility Service +parent.title=Implementing Accessibility +parent.link=index.html + +trainingnavtop=true +previous.title=Developing Accessible Applications +previous.link=accessible-app.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#create">Create Your Accessibility Service</a></li> + <li><a href="#configure">Configure Your Accessibility Service</a></li> + <li><a href="#events">Respond to AccessibilityEvents</a></li> + <li><a href="#query">Query the View Heirarchy for More Context</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/topics/ui/accessibility/services.html">Building + Accessibility Services</a></li> +</ul> + +</div> +</div> + + +<p>Accessibility services are a feature of the Android framework designed to +provide alternative navigation feedback to the user on behalf of applications +installed on Android devices. An accessibility service can communicate to the +user on the application's behalf, such as converting text to speech, or haptic +feedback when a user is hovering on an important area of the screen. This +lesson covers how to create an accessibility service, process information +received from the application, and report that information back to the +user.</p> + + +<h2 id="create">Create Your Accessibility Service</h2> +<p>An accessibility service can be bundled with a normal application, or created +as a standalone Android project. The steps to creating the service are the same +in either situation. Within your project, create a class that extends {@link +android.accessibilityservice.AccessibilityService}.</p> + +<pre> +package com.example.android.apis.accessibility; + +import android.accessibilityservice.AccessibilityService; + +public class MyAccessibilityService extends AccessibilityService { +... + @Override + public void onAccessibilityEvent(AccessibilityEvent event) { + } + + @Override + public void onInterrupt() { + } + +... +} +</pre> + +<p>Like any other service, you also declare it in the manifest file. +Remember to specify that it handles the {@code android.accessibilityservice} intent, +so that the service is called when applications fire an +{@link android.view.accessibility.AccessibilityEvent}.</p> + +<pre> +<application ...> +... +<service android:name=".MyAccessibilityService"> + <intent-filter> + <action android:name="android.accessibilityservice.AccessibilityService" /> + </intent-filter> + . . . +</service> +... +</application> +</pre> + +<p>If you created a new project for this service, and don't plan on having an +application, you can remove the starter Activity class (usually called MainActivity.java) from your source. Remember to +also remove the corresponding activity element from your manifest.</p> + +<h2 id="configure">Configure Your Accessibility Service</h2> +<p>Setting the configuration variables for your accessibility service tells the +system how and when you want it to run. Which event types would you like to +respond to? Should the service be active for all applications, or only specific +package names? What different feedback types does it use?</p> + +<p>You have two options for how to set these variables. The +backwards-compatible option is to set them in code, using {@link +android.accessibilityservice.AccessibilityService#setServiceInfo(android.accessibilityservice.AccessibilityServiceInfo)}. +To do that, override the {@link +android.accessibilityservice.AccessibilityService#onServiceConnected()} method +and configure your service in there.</p> + +<pre> +@Override +public void onServiceConnected() { + // Set the type of events that this service wants to listen to. Others + // won't be passed to this service. + info.eventTypes = AccessibilityEvent.TYPE_VIEW_CLICKED | + AccessibilityEvent.TYPE_VIEW_FOCUSED; + + // If you only want this service to work with specific applications, set their + // package names here. Otherwise, when the service is activated, it will listen + // to events from all applications. + info.packageNames = new String[] + {"com.example.android.myFirstApp", "com.example.android.mySecondApp"}; + + // Set the type of feedback your service will provide. + info.feedbackType = AccessibilityServiceInfo.FEEDBACK_SPOKEN; + + // Default services are invoked only if no package-specific ones are present + // for the type of AccessibilityEvent generated. This service *is* + // application-specific, so the flag isn't necessary. If this was a + // general-purpose service, it would be worth considering setting the + // DEFAULT flag. + + // info.flags = AccessibilityServiceInfo.DEFAULT; + + info.notificationTimeout = 100; + + this.setServiceInfo(info); + +} +</pre> + +<p>Starting with Android 4.0, there is a second option available: configure the +service using an XML file. Certain configuration options like +{@link android.R.attr#canRetrieveWindowContent} are only available if you +configure your service using XML. The same configuration options above, defined +using XML, would look like this:</p> + +<pre> +<accessibility-service + android:accessibilityEventTypes="typeViewClicked|typeViewFocused" + android:packageNames="com.example.android.myFirstApp, com.example.android.mySecondApp" + android:accessibilityFeedbackType="feedbackSpoken" + android:notificationTimeout="100" + android:settingsActivity="com.example.android.apis.accessibility.TestBackActivity" + android:canRetrieveWindowContent="true" +/> +</pre> + +<p>If you go the XML route, be sure to reference it in your manifest, by adding +a <a +href="{@docRoot}guide/topics/manifest/meta-data-element.html"><meta-data></a> tag to +your service declaration, pointing at the XML file. If you stored your XML file +in {@code res/xml/serviceconfig.xml}, the new tag would look like this:</p> + +<pre> +<service android:name=".MyAccessibilityService"> + <intent-filter> + <action android:name="android.accessibilityservice.AccessibilityService" /> + </intent-filter> + <meta-data android:name="android.accessibilityservice" + android:resource="@xml/serviceconfig" /> +</service> +</pre> + +<h2 id="events">Respond to AccessibilityEvents</h2> +<p>Now that your service is set up to run and listen for events, write some code +so it knows what to do when an {@link +android.view.accessibility.AccessibilityEvent} actually arrives! Start by +overriding the {@link +android.accessibilityservice.AccessibilityService#onAccessibilityEvent} method. +In that method, use {@link +android.view.accessibility.AccessibilityEvent#getEventType} to determine the +type of event, and {@link +android.view.accessibility.AccessibilityEvent#getContentDescription} to extract +any label text associated with the fiew that fired the event.</pre> + +<pre> +@Override +public void onAccessibilityEvent(AccessibilityEvent event) { + final int eventType = event.getEventType(); + String eventText = null; + switch(eventType) { + case AccessibilityEvent.TYPE_VIEW_CLICKED: + eventText = "Focused: "; + break; + case AccessibilityEvent.TYPE_VIEW_FOCUSED: + eventText = "Focused: "; + break; + } + + eventText = eventText + event.getContentDescription(); + + // Do something nifty with this text, like speak the composed string + // back to the user. + speakToUser(eventText); + ... +} +</pre> + +<h2 id="query">Query the View Heirarchy for More Context</h2> +<p>This step is optional, but highly useful. One of the new features in Android +4.0 (API Level 14) is the ability for an +{@link android.accessibilityservice.AccessibilityService} to query the view +hierarchy, collecting information about the the UI component that generated an event, and +its parent and children. In order to do this, make sure that you set the +following line in your XML configuration:</p> +<pre> +android:canRetrieveWindowContent="true" +</pre> +<p>Once that's done, get an {@link +android.view.accessibility.AccessibilityNodeInfo} object using {@link +android.view.accessibility.AccessibilityEvent#getSource}. This call only +returns an object if the window where the event originated is still the active +window. If not, it will return null, so <em>behave accordingly</em>. The +following example is a snippet of code that, when it receives an event, does +the following: +<ol> + <li>Immediately grab the parent of the view where the event originated</li> + <li>In that view, look for a label and a check box as children views</li> + <li>If it finds them, create a string to report to the user, indicating + the label and whether it was checked or not.</li> + <li>If at any point a null value is returned while traversing the view + hierarchy, the method quietly gives up.</li> +</ol> + +<pre> + +// Alternative onAccessibilityEvent, that uses AccessibilityNodeInfo + +@Override +public void onAccessibilityEvent(AccessibilityEvent event) { + + AccessibilityNodeInfo source = event.getSource(); + if (source == null) { + return; + } + + // Grab the parent of the view that fired the event. + AccessibilityNodeInfo rowNode = getListItemNodeInfo(source); + if (rowNode == null) { + return; + } + + // Using this parent, get references to both child nodes, the label and the checkbox. + AccessibilityNodeInfo labelNode = rowNode.getChild(0); + if (labelNode == null) { + rowNode.recycle(); + return; + } + + AccessibilityNodeInfo completeNode = rowNode.getChild(1); + if (completeNode == null) { + rowNode.recycle(); + return; + } + + // Determine what the task is and whether or not it's complete, based on + // the text inside the label, and the state of the check-box. + if (rowNode.getChildCount() < 2 || !rowNode.getChild(1).isCheckable()) { + rowNode.recycle(); + return; + } + + CharSequence taskLabel = labelNode.getText(); + final boolean isComplete = completeNode.isChecked(); + String completeStr = null; + + if (isComplete) { + completeStr = getString(R.string.checked); + } else { + completeStr = getString(R.string.not_checked); + } + String reportStr = taskLabel + completeStr; + speakToUser(reportStr); +} + +</pre> + +<p>Now you have a complete, functioning accessibility service. Try configuring +how it interacts with the user, by adding Android's <a + href="http://developer.android.com/resources/articles/tts.html">text-to-speech + engine</a>, or using a {@link android.os.Vibrator} to provide haptic +feedback!</p> diff --git a/docs/html/training/backward-compatible-ui/abstracting.jd b/docs/html/training/backward-compatible-ui/abstracting.jd new file mode 100644 index 0000000..1141b54 --- /dev/null +++ b/docs/html/training/backward-compatible-ui/abstracting.jd @@ -0,0 +1,111 @@ +page.title=Abstracting the New APIs +parent.title=Creating Backward-Compatible UIs +parent.link=index.html + +trainingnavtop=true +next.title=Proxying to the New APIs +next.link=new-implementation.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to:</h2> +<ul> + <li><a href="#prepare-abstraction">Prepare for Abstraction</a></li> + <li><a href="#create-abstract-tab">Create an Abstract Tab Interface</a></li> + <li><a href="#abstract-actionbar-tab">Abstract ActionBar.Tab</a></li> + <li><a href="#abstract-actionbar-methods">Abstract ActionBar Tab Methods</a></li> +</ul> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a></li> + <li><a href="{@docRoot}guide/topics/ui/actionbar.html#Tabs">Action Bar Tabs</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/TabCompat.zip" + class="button">Download the sample app</a> +<p class="filename">TabCompat.zip</p> +</div> + +</div> +</div> + +<p>Suppose you want to use <a href="{@docRoot}guide/topics/ui/actionbar.html#Tabs">action bar tabs</a> as the primary form of top-level navigation in your application. Unfortunately, the {@link android.app.ActionBar} APIs are only available in Android 3.0 or later (API level 11+). Thus, if you want to distribute your application to devices running earlier versions of the platform, you need to provide an implementation that supports the newer API while providing a fallback mechanism that uses older APIs.</p> + +<p>In this class, you build a tabbed user interface (UI) component that uses abstract classes with version-specific implementations to provide backward-compatibility. This lesson describes how to create an abstraction layer for the new tab APIs as the first step toward building the tab component.</p> + +<h2 id="prepare-abstraction">Prepare for Abstraction</h2> + +<p><a href="http://en.wikipedia.org/wiki/Abstraction_(computer_science)">Abstraction</a> in the Java programming language involves the creation of one or more interfaces or abstract classes to hide implementation details. In the case of newer Android APIs, you can use abstraction to build version-aware components that use the current APIs on newer devices, and fallback to older, more compatible APIs on older devices.</p> + +<p>When using this approach, you first determine what newer classes you want to be able to use in a backward compatible way, then create abstract classes, based on the public interfaces of the newer classes. In defining the abstraction interfaces, you should mirror the newer API as much as possible. This maximizes forward-compatibility and makes it easier to drop the abstraction layer in the future when it is no longer necessary.</p> + +<p>After creating abstract classes for these new APIs, any number of implementations can be created and chosen at runtime. For the purposes of backward-compatibility, these implementations can vary by required API level. Thus, one implementation may use recently released APIs, while others can use older APIs.</p> + +<h2 id="create-abstract-tab">Create an Abstract Tab Interface</h2> + +<p>In order to create a backward-compatible version of tabs, you should first determine which features and specific APIs your application requires. In the case of top-level section tabs, suppose you have the following functional requirements:</p> + +<ol> +<li>Tab indicators should show text and an icon.</li> +<li>Tabs can be associated with a fragment instance.</li> +<li>The activity should be able to listen for tab changes.</li> +</ol> + +<p>Preparing these requirements in advance allows you to control the scope of your abstraction layer. This means that you can spend less time creating multiple implementations of your abstraction layer and begin using your new backward-compatible implementation sooner.</p> + +<p>The key APIs for tabs are in {@link android.app.ActionBar} and {@link android.app.ActionBar.Tab ActionBar.Tab}. These are the APIs to abstract in order to make your tabs version-aware. The requirements for this example project call for compatibility back to Eclair (API level 5) while taking advantage of the new tab features in Honeycomb (API Level 11). A diagram of the class structure to support these two implementations and their abstract base classes (or interfaces) is shown below.</p> + +<img src="{@docRoot}images/training/backward-compatible-ui-classes.png" + alt="Class diagram of abstract base classes and version-specific implementations." id="figure-classes"> + +<p class="img-caption"><strong>Figure 1.</strong> Class diagram of abstract base classes and version-specific implementations.</p> + +<h2 id="abstract-actionbar-tab">Abstract ActionBar.Tab</h2> + +<p>Get started on building your tab abstraction layer by creating an abstract class representing a tab, that mirrors the {@link android.app.ActionBar.Tab ActionBar.Tab} interface:</p> + +<pre> +public abstract class CompatTab { + ... + public abstract CompatTab setText(int resId); + public abstract CompatTab setIcon(int resId); + public abstract CompatTab setTabListener( + CompatTabListener callback); + public abstract CompatTab setFragment(Fragment fragment); + + public abstract CharSequence getText(); + public abstract Drawable getIcon(); + public abstract CompatTabListener getCallback(); + public abstract Fragment getFragment(); + ... +} +</pre> + +<p>You can use an abstract class instead of an interface here to simplify the implementation of common features such as association of tab objects with activities (not shown in the code snippet).</p> + +<h2 id="abstract-actionbar-methods">Abstract ActionBar Tab Methods</h2> + +<p>Next, define an abstract class that allows you to create and add tabs to an activity, like {@link android.app.ActionBar#newTab ActionBar.newTab()} and {@link android.app.ActionBar#addTab ActionBar.addTab()}:</p> + +<pre> +public abstract class TabHelper { + ... + + public CompatTab newTab(String tag) { + // This method is implemented in a later lesson. + } + + public abstract void addTab(CompatTab tab); + + ... +} +</pre> + +<p>In the next lessons, you create implementations for <code>TabHelper</code> and <code>CompatTab</code> that work across both older and newer platform versions.</p> diff --git a/docs/html/training/backward-compatible-ui/index.jd b/docs/html/training/backward-compatible-ui/index.jd new file mode 100644 index 0000000..7e27e68 --- /dev/null +++ b/docs/html/training/backward-compatible-ui/index.jd @@ -0,0 +1,57 @@ +page.title=Creating Backward-Compatible UIs + +trainingnavtop=true +startpage=true +next.title=Abstracting the New Implementation +next.link=abstracting.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>Dependencies and prerequisites</h2> + +<ul> + <li>API level 5</li> + <li><a href="{@docRoot}sdk/compatibility-library.html">The Android Support Package</a></li> +</ul> + +<h2>You should also read</h2> + +<ul> + <li><a href="{@docRoot}resources/samples/ActionBarCompat/index.html">ActionBarCompat</a></li> + <li><a href="http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html">How to have your (Cup)cake and eat it too</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/TabCompat.zip" + class="button">Download the sample app</a> +<p class="filename">TabCompat.zip</p> +</div> + +</div> +</div> + +<p>This class demonstrates how to use UI components and APIs available in newer versions of Android in a backward-compatible way, ensuring that your application still runs on previous versions of the platform.</p> + +<p>Throughout this class, the new <a href="{@docRoot}guide/topics/ui/actionbar.html#Tabs">Action Bar Tabs</a> feature introduced in Android 3.0 (API level 11) serves as the guiding example, but you can apply these techniques to other UI components and API features.</p> + +<h2 id="lessons">Lessons</h2> + + +<dl> + <dt><strong><a href="abstracting.html">Abstracting the New APIs</a></strong></dt> + <dd>Determine which features and APIs your application needs. Learn how to define application-specific, intermediary Java interfaces that abstract the implementation of the UI component to your application.</dd> + + <dt><strong><a href="new-implementation.html">Proxying to the New APIs</a></strong></dt> + <dd>Learn how to create an implementation of your interface that uses newer APIs.</dd> + + <dt><strong><a href="older-implementation.html">Creating an Implementation with Older APIs</a></strong></dt> + <dd>Learn how to create a custom implementation of your interface that uses older APIs.</dd> + + <dt><strong><a href="using-component.html">Using the Version-Aware Component</a></strong></dt> + <dd>Learn how to choose an implementation to use at runtime, and begin using the interface in your application.</dd> +</dl> diff --git a/docs/html/training/backward-compatible-ui/new-implementation.jd b/docs/html/training/backward-compatible-ui/new-implementation.jd new file mode 100644 index 0000000..5b8b51c --- /dev/null +++ b/docs/html/training/backward-compatible-ui/new-implementation.jd @@ -0,0 +1,113 @@ +page.title=Proxying to the New APIs +parent.title=Creating Backward-Compatible UIs +parent.link=index.html + +trainingnavtop=true +previous.title=Abstracting the New APIs +previous.link=abstracting.html +next.title=Creating an Implementation with Older APIs +next.link=older-implementation.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to:</h2> +<ol> + <li><a href="#new-tabs">Implement Tabs Using New APIs</a></li> + <li><a href="#compattabhoneycomb">Implement CompatTabHoneycomb</a></li> + <li><a href="#tabhelperhoneycomb">Implement TabHelperHoneycomb</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a></li> + <li><a href="{@docRoot}guide/topics/ui/actionbar.html#Tabs">Action Bar Tabs</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/TabCompat.zip" + class="button">Download the sample app</a> +<p class="filename">TabCompat.zip</p> +</div> + +</div> +</div> + +<p>This lesson shows you how to subclass the <code>CompatTab</code> and <code>TabHelper</code> abstract classes and use new APIs. Your application can use this implementation on devices running a platform version that supports them.</p> + +<h2 id="new-tabs">Implement Tabs Using New APIs</h2> + +<p>The concrete classes for <code>CompatTab</code> and <code>TabHelper</code> that use newer APIs are a <em>proxy</em> implementation. Since the abstract classes defined in the previous lesson mirror the new APIs (class structure, method signatures, etc.), the concrete classes that use these newer APIs simply proxy method calls and their results.</p> + +<p>You can directly use newer APIs in these concrete classes—and not crash on earlier devices—because of lazy class loading. Classes are loaded and initialized on first access—instantiating the class or accessing one of its static fields or methods for the first time. Thus, as long as you don't instantiate the Honeycomb-specific implementations on pre-Honeycomb devices, the Dalvik VM won't throw any {@link java.lang.VerifyError} exceptions.</p> + +<p>A good naming convention for this implementation is to append the API level or platform version code name corresponding to the APIs required by the concrete classes. For example, the native tab implementation can be provided by <code>CompatTabHoneycomb</code> and <code>TabHelperHoneycomb</code> classes, since they rely on APIs available in Android 3.0 (API level 11) or later.</p> + +<img src="{@docRoot}images/training/backward-compatible-ui-classes-honeycomb.png" + alt="Class diagram for the Honeycomb implementation of tabs." id="figure-classes"> + +<p class="img-caption"><strong>Figure 1.</strong> Class diagram for the Honeycomb implementation of tabs.</p> + +<h2 id="compattabhoneycomb">Implement CompatTabHoneycomb</h2> + +<p><code>CompatTabHoneycomb</code> is the implementation of the <code>CompatTab</code> abstract class that <code>TabHelperHoneycomb</code> uses to reference individual tabs. <code>CompatTabHoneycomb</code> simply proxies all method calls to its contained {@link android.app.ActionBar.Tab} object.</p> + +<p>Begin implementing <code>CompatTabHoneycomb</code> using the new {@link android.app.ActionBar.Tab ActionBar.Tab} APIs:</p> + +<pre> +public class CompatTabHoneycomb extends CompatTab { + // The native tab object that this CompatTab acts as a proxy for. + ActionBar.Tab mTab; + ... + + protected CompatTabHoneycomb(FragmentActivity activity, String tag) { + ... + // Proxy to new ActionBar.newTab API + mTab = activity.getActionBar().newTab(); + } + + public CompatTab setText(int resId) { + // Proxy to new ActionBar.Tab.setText API + mTab.setText(resId); + return this; + } + + ... + // Do the same for other properties (icon, callback, etc.) +} +</pre> + +<h2 id="tabhelperhoneycomb">Implement TabHelperHoneycomb</h2> + +<p><code>TabHelperHoneycomb</code> is the implementation of the <code>TabHelper</code> abstract class that proxies method calls to an actual {@link android.app.ActionBar}, obtained from its contained {@link android.app.Activity}.</p> + +<p>Implement <code>TabHelperHoneycomb</code>, proxying method calls to the {@link android.app.ActionBar} API:</p> + +<pre> +public class TabHelperHoneycomb extends TabHelper { + ActionBar mActionBar; + ... + + protected void setUp() { + if (mActionBar == null) { + mActionBar = mActivity.getActionBar(); + mActionBar.setNavigationMode( + ActionBar.NAVIGATION_MODE_TABS); + } + } + + public void addTab(CompatTab tab) { + ... + // Tab is a CompatTabHoneycomb instance, so its + // native tab object is an ActionBar.Tab. + mActionBar.addTab((ActionBar.Tab) tab.getTab()); + } + + // The other important method, newTab() is part of + // the base implementation. +} +</pre>
\ No newline at end of file diff --git a/docs/html/training/backward-compatible-ui/older-implementation.jd b/docs/html/training/backward-compatible-ui/older-implementation.jd new file mode 100644 index 0000000..5006123 --- /dev/null +++ b/docs/html/training/backward-compatible-ui/older-implementation.jd @@ -0,0 +1,126 @@ +page.title=Creating an Implementation with Older APIs +parent.title=Creating Backward-Compatible UIs +parent.link=index.html + +trainingnavtop=true +previous.title=Proxying to the New APIs +previous.link=new-implementation.html +next.title=Using the Version-Aware Component +next.link=using-component.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to:</h2> +<ol> + <li><a href="#decide-substitute">Decide on a Substitute Solution</a></li> + <li><a href="#older-tabs">Implement Tabs Using Older APIs</a></li> +</ol> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/TabCompat.zip" + class="button">Download the sample app</a> +<p class="filename">TabCompat.zip</p> +</div> + +</div> +</div> + + +<p>This lesson discusses how to create an implementation that mirrors newer APIs yet supports older devices.</p> + +<h2 id="decide-substitute">Decide on a Substitute Solution</h2> + +<p>The most challenging task in using newer UI features in a backward-compatible way is deciding on and implementing an older (fallback) solution for older platform versions. In many cases, it's possible to fulfill the purpose of these newer UI components using older UI framework features. For example:</p> + +<ul> + +<li> +<p>Action bars can be implemented using a horizontal {@link android.widget.LinearLayout} containing image buttons, either as custom title bars or as views in your activity layout. Overflow actions can be presented under the device <em>Menu</em> button.</p> +</li> + +<li> +<p>Action bar tabs can be implemented using a horizontal {@link android.widget.LinearLayout} containing buttons, or using the {@link android.widget.TabWidget} UI element.</p> +</li> + +<li> +<p>{@link android.widget.NumberPicker} and {@link android.widget.Switch} widgets can be implemented using {@link android.widget.Spinner} and {@link android.widget.ToggleButton} widgets, respectively.</p> +</li> + +<li> +<p>{@link android.widget.ListPopupWindow} and {@link android.widget.PopupMenu} widgets can be implemented using {@link android.widget.PopupWindow} widgets.</p> +</li> + +</ul> + +<p>There generally isn't a one-size-fits-all solution for backporting newer UI components to older devices. Be mindful of the user experience: on older devices, users may not be familiar with newer design patterns and UI components. Give some thought as to how the same functionality can be delivered using familiar elements. In many cases this is less of a concern—if newer UI components are prominent in the application ecosystem (such as the action bar), or where the interaction model is extremely simple and intuitive (such as swipe views using a {@link android.support.v4.view.ViewPager}).</p> + +<h2 id="older-tabs">Implement Tabs Using Older APIs</h2> + +<p>To create an older implementation of action bar tabs, you can use a {@link android.widget.TabWidget} and {@link android.widget.TabHost} (although one can alternatively use horizontally laid-out {@link android.widget.Button} widgets). Implement this in classes called <code>TabHelperEclair</code> and <code>CompatTabEclair</code>, since this implementation uses APIs introduced no later than Android 2.0 (Eclair).</p> + + +<img src="{@docRoot}images/training/backward-compatible-ui-classes-eclair.png" + alt="Class diagram for the Eclair implementation of tabs." id="figure-classes"> + +<p class="img-caption"><strong>Figure 1.</strong> Class diagram for the Eclair implementation of tabs.</p> + +<p>The <code>CompatTabEclair</code> implementation stores tab properties such as the tab text and icon in instance variables, since there isn't an {@link android.app.ActionBar.Tab ActionBar.Tab} object available to handle this storage:</p> + +<pre> +public class CompatTabEclair extends CompatTab { + // Store these properties in the instance, + // as there is no ActionBar.Tab object. + private CharSequence mText; + ... + + public CompatTab setText(int resId) { + // Our older implementation simply stores this + // information in the object instance. + mText = mActivity.getResources().getText(resId); + return this; + } + + ... + // Do the same for other properties (icon, callback, etc.) +} +</pre> + +<p>The <code>TabHelperEclair</code> implementation makes use of methods on the +{@link android.widget.TabHost} widget for creating {@link android.widget.TabHost.TabSpec} +objects and tab indicators:</p> + +<pre> +public class TabHelperEclair extends TabHelper { + private TabHost mTabHost; + ... + + protected void setUp() { + if (mTabHost == null) { + // Our activity layout for pre-Honeycomb devices + // must contain a TabHost. + mTabHost = (TabHost) mActivity.findViewById( + android.R.id.tabhost); + mTabHost.setup(); + } + } + + public void addTab(CompatTab tab) { + ... + TabSpec spec = mTabHost + .newTabSpec(tag) + .setIndicator(tab.getText()); // And optional icon + ... + mTabHost.addTab(spec); + } + + // The other important method, newTab() is part of + // the base implementation. +} +</pre> + +<p>You now have two implementations of <code>CompatTab</code> and <code>TabHelper</code>: one that works on devices running Android 3.0 or later and uses new APIs, and another that works on devices running Android 2.0 or later and uses older APIs. The next lesson discusses using these implementations in your application.</p> diff --git a/docs/html/training/backward-compatible-ui/using-component.jd b/docs/html/training/backward-compatible-ui/using-component.jd new file mode 100644 index 0000000..4bf7fa0 --- /dev/null +++ b/docs/html/training/backward-compatible-ui/using-component.jd @@ -0,0 +1,143 @@ +page.title=Using the Version-Aware Component +parent.title=Creating Backward-Compatible UIs +parent.link=index.html + +trainingnavtop=true +previous.title=Creating an Implementation with Older APIs +previous.link=older-implementation.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to:</h2> +<ol> + <li><a href="#switching-logic">Add the Switching Logic</a></li> + <li><a href="#layout">Create a Version-Aware Activity Layout</a></li> + <li><a href="#use-tabhelper">Use TabHelper in Your Activity</a></li> +</ol> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/TabCompat.zip" + class="button">Download the sample app</a> +<p class="filename">TabCompat.zip</p> +</div> + +</div> +</div> + +<p>Now that you have two implementations of <code>TabHelper</code> and <code>CompatTab</code>—one for Android 3.0 and later and one for earlier versions of the platform—it's time to do something with these implementations. This lesson discusses creating the logic for switching between these implementations, creating version-aware layouts, and finally using the backward-compatible UI component.</p> + +<h2 id="switching-logic">Add the Switching Logic</h2> + +<p>The <code>TabHelper</code> abstract class acts as a <a href="http://en.wikipedia.org/wiki/Factory_(software_concept)">factory</a> for creating version-appropriate <code>TabHelper</code> and <code>CompatTab</code> instances, based on the current device's platform version:</p> + +<pre> +public abstract class TabHelper { + ... + // Usage is TabHelper.createInstance(activity) + public static TabHelper createInstance(FragmentActivity activity) { + if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { + return new TabHelperHoneycomb(activity); + } else { + return new TabHelperEclair(activity); + } + } + + // Usage is mTabHelper.newTab("tag") + public CompatTab newTab(String tag) { + if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { + return new CompatTabHoneycomb(mActivity, tag); + } else { + return new CompatTabEclair(mActivity, tag); + } + } + ... +} +</pre> + +<h2 id="layout">Create a Version-Aware Activity Layout</h2> + +<p>The next step is to provide layouts for your activity that can support the two tab implementations. For the older implementation (<code>TabHelperEclair</code>), you need to ensure that your activity layout contains a {@link android.widget.TabWidget} and {@link android.widget.TabHost}, along with a container for tab contents:</p> + +<p><strong>res/layout/main.xml:</strong></p> + +<pre> +<!-- This layout is for API level 5-10 only. --> +<TabHost xmlns:android="http://schemas.android.com/apk/res/android" + android:id="@android:id/tabhost" + android:layout_width="match_parent" + android:layout_height="match_parent"> + + <LinearLayout + android:orientation="vertical" + android:layout_width="match_parent" + android:layout_height="match_parent" + android:padding="5dp"> + + <TabWidget + android:id="@android:id/tabs" + android:layout_width="match_parent" + android:layout_height="wrap_content" /> + + <FrameLayout + android:id="@android:id/tabcontent" + android:layout_width="match_parent" + android:layout_height="0dp" + android:layout_weight="1" /> + + </LinearLayout> +</TabHost> +</pre> + +<p>For the <code>TabHelperHoneycomb</code> implementation, all you need is a {@link android.widget.FrameLayout} to contain the tab contents, since the tab indicators are provided by the {@link android.app.ActionBar}:</p> + +<p><strong>res/layout-v11/main.xml:</strong></p> + +<pre> +<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" + android:id="@android:id/tabcontent" + android:layout_width="match_parent" + android:layout_height="match_parent" /> +</pre> + +<p>At runtime, Android will decide which version of the <code>main.xml</code> layout to inflate depending on the platform version. This is the same logic shown in the previous section to determine which <code>TabHelper</code> implementation to use.</p> + +<h2 id="use-tabhelper">Use TabHelper in Your Activity</h2> + +<p>In your activity's {@link android.app.Activity#onCreate onCreate()} method, you can obtain a <code>TabHelper</code> object and add tabs with the following code:</p> + +<pre> +{@literal @}Override +public void onCreate(Bundle savedInstanceState) { + setContentView(R.layout.main); + + TabHelper tabHelper = TabHelper.createInstance(this); + tabHelper.setUp(); + + CompatTab photosTab = tabHelper + .newTab("photos") + .setText(R.string.tab_photos); + tabHelper.addTab(photosTab); + + CompatTab videosTab = tabHelper + .newTab("videos") + .setText(R.string.tab_videos); + tabHelper.addTab(videosTab); +} +</pre> + +<p>When running the application, this code inflates the correct activity layout and instantiates either a <code>TabHelperHoneycomb</code> or <code>TabHelperEclair</code> object. The concrete class that's actually used is opaque to the activity, since they share the common <code>TabHelper</code> interface.</p> + +<p>Below are two screenshots of this implementation running on an Android 2.3 and Android 4.0 device.</p> + +<img src="{@docRoot}images/training/backward-compatible-ui-gb.png" + alt="Example screenshot of tabs running on an Android 2.3 device (using TabHelperEclair)." width="200"> + +<img src="{@docRoot}images/training/backward-compatible-ui-ics.png" + alt="Example screenshots of tabs running on an Android 4.0 device (using TabHelperHoneycomb)." width="200"> + +<p class="img-caption"><strong>Figure 1.</strong> Example screenshots of backward-compatible tabs running on an Android 2.3 device (using <code>TabHelperEclair</code>) and an Android 4.0 device (using <code>TabHelperHoneycomb</code>).</p> diff --git a/docs/html/training/basics/firstapp/building-ui.jd b/docs/html/training/basics/firstapp/building-ui.jd new file mode 100644 index 0000000..847163a --- /dev/null +++ b/docs/html/training/basics/firstapp/building-ui.jd @@ -0,0 +1,363 @@ +page.title=Building a Simple User Interface +parent.title=Building Your First App +parent.link=index.html + +trainingnavtop=true +previous.title=Running Your App +previous.link=running-app.html +next.title=Starting Another Activity +next.link=starting-activity.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> + +<ol> + <li><a href="#LinearLayout">Use a Linear Layout</a></li> + <li><a href="#TextInput">Add a Text Input Box</a></li> + <li><a href="#Strings">Add String Resources</a></li> + <li><a href="#Button">Add a Button</a></li> + <li><a href="#Weight">Make the Input Box Fill in the Screen Width</a></li> +</ol> + + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/topics/ui/declaring-layout.html">XML Layouts</a></li> +</ul> + + +</div> +</div> + + + +<p>The graphical user interface for an Android app is built using a hierarchy of {@link +android.view.View} and {@link android.view.ViewGroup} objects. {@link android.view.View} objects are +usually UI widgets such as a button or text field and {@link android.view.ViewGroup} objects are +invisible view containers that define how the child views are laid out, such as in a +grid or a vertical list.</p> + +<p>Android provides an XML vocabulary that corresponds to the subclasses of {@link +android.view.View} and {@link android.view.ViewGroup} so you can define your UI in XML with a +hierarchy of view elements.</p> + + +<div class="sidebox-wrapper"> +<div class="sidebox"> + <h2>Alternative Layouts</h2> + <p>Separating the UI layout into XML files is important for several reasons, +but it's especially important on Android because it allows you to define alternative layouts for +different screen sizes. For example, you can create two versions of a layout and tell +the system to use one on "small" screens and the other on "large" screens. For more information, +see the class about <a +href="{@docRoot}training/supporting-hardware/index.html">Supporting Various Hardware</a>.</p> +</div> +</div> + +<img src="{@docRoot}images/viewgroup.png" alt="" /> +<p class="img-caption"><strong>Figure 1.</strong> Illustration of how {@link +android.view.ViewGroup} objects form branches in the layout and contain {@link +android.view.View} objects.</p> + +<p>In this lesson, you'll create a layout in XML that includes a text input field and a +button. In the following lesson, you'll respond when the button is pressed by sending the +content of the text field to another activity.</p> + + + +<h2 id="LinearLayout">Use a Linear Layout</h2> + +<p>Open the <code>main.xml</code> file from the <code>res/layout/</code> +directory (every new Android project includes this file by default).</p> + +<p class="note"><strong>Note:</strong> In Eclipse, when you open a layout file, you’re first shown +the ADT Layout Editor. This is an editor that helps you build layouts using WYSIWYG tools. For this +lesson, you’re going to work directly with the XML, so click the <em>main.xml</em> tab at +the bottom of the screen to open the XML editor.</p> + +<p>By default, the <code>main.xml</code> file includes a layout with a {@link +android.widget.LinearLayout} root view group and a {@link android.widget.TextView} child view. +You’re going to re-use the {@link android.widget.LinearLayout} in this lesson, but change its +contents and layout orientation.</p> + +<p>First, delete the {@link android.widget.TextView} element and change the value +<a href="{@docRoot}reference/android/widget/LinearLayout.html#attr_android:orientation">{@code +android:orientation}</a> to be <code>"horizontal"</code>. The result looks like this:</p> + +<pre> +<?xml version="1.0" encoding="utf-8"?> +<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" + android:layout_width="fill_parent" + android:layout_height="fill_parent" + android:orientation="horizontal" > +</LinearLayout> +</pre> + +<p>{@link android.widget.LinearLayout} is a view group (a subclass of {@link +android.view.ViewGroup}) that lays out child views in either a vertical or horizontal orientation, +as specified by the <a +href="{@docRoot}reference/android/widget/LinearLayout.html#attr_android:orientation">{@code +android:orientation}</a> attribute. Each child of a {@link android.widget.LinearLayout} appears on +the screen in the order in which it appears in the XML.</p> + +<p>The other two attributes, <a +href="{@docRoot}reference/android/view/View.html#attr_android:layout_width">{@code +android:layout_width}</a> and <a +href="{@docRoot}reference/android/view/View.html#attr_android:layout_height">{@code +android:layout_height}</a>, are required for all views in order to specify their size.</p> + +<p>Because the {@link android.widget.LinearLayout} is the root view in the layout, it should fill +the entire screen area that's +available to the app by setting the width and height to +<code>"fill_parent"</code>.</p> + +<p class="note"><strong>Note:</strong> Beginning with Android 2.2 (API level 8), +<code>"fill_parent"</code> has been renamed <code>"match_parent"</code> to better reflect the +behavior. The reason is that if you set a view to <code>"fill_parent"</code> it does not expand to +fill the remaining space after sibling views are considered, but instead expands to +<em>match</em> the size of the parent view no matter what—it will overlap any sibling +views.</p> + +<p>For more information about layout properties, see the <a +href="{@docRoot}guide/topics/ui/declaring-layout.html">XML Layout</a> guide.</p> + + + +<h2 id="TextInput">Add a Text Input Box</h2> + +<p>To create a user-editable text box, add an {@link android.widget.EditText +<EditText>} element inside the {@link android.widget.LinearLayout <LinearLayout>}. The {@link +android.widget.EditText} class is a subclass of {@link android.view.View} that displays an editable +text box.</p> + +<p>Like every {@link android.view.View} object, you must define certain XML attributes to specify +the {@link android.widget.EditText} object's properties. Here’s how you should declare it +inside the {@link android.widget.LinearLayout <LinearLayout>} element:</p> + +<pre> + <EditText android:id="@+id/edit_message" + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:hint="@string/edit_message" /> +</pre> + + +<div class="sidebox-wrapper"> +<div class="sidebox"> + <h3>About resource objects</h3> + <p>A resource object is simply a unique integer name that's associated with an app resource, +such as a bitmap, layout file, or string.</p> + <p>Every resource has a +corresponding resource object defined in your project's {@code gen/R.java} file. You can use the +object names in the {@code R} class to refer to your resources, such as when you need to specify a +string value for the <a +href="{@docRoot}reference/android/widget/TextView.html#attr_android:hint">{@code android:hint}</a> +attribute. You can also create arbitrary resource IDs that you associate with a view using the <a +href="{@docRoot}reference/android/view/View.html#attr_android:id">{@code android:id}</a> attribute, +which allows you to reference that view from other code.</p> + <p>The SDK tools generate the {@code R.java} each time you compile your app. You should never +modify this file by hand.</p> +</div> +</div> + +<p>About these attributes:</p> + +<dl> +<dt><a href="{@docRoot}reference/android/view/View.html#attr_android:id">{@code android:id}</a></dt> +<dd>This provides a unique identifier for the view, which you can use to reference the object +from your app code, such as to read and manipulate the object (you'll see this in the next +lesson). + +<p>The at-symbol (<code>@</code>) is required when you want to refer to a resource object from +XML, followed by the resource type ({@code id} in this case), then the resource name ({@code +edit_message}). (Other resources can use the same name as long as they are not the same +resource type—for example, the string resource uses the same name.)</p> + +<p>The plus-symbol (<code>+</code>) is needed only when you're defining a resource ID for the +first time. It tells the SDK tools that the resource ID needs to be created. Thus, when the app is +compiled, the SDK tools use the ID value, <code>edit_message</code>, to create a new identifier in +your project's {@code gen/R.java} file that is now assiciated with the {@link +android.widget.EditText} element. Once the resource ID is created, other references to the ID do not +need the plus symbol. See the sidebox for more information about resource objects.</p></dd> + +<dt><a +href="{@docRoot}reference/android/view/View.html#attr_android:layout_width">{@code +android:layout_width}</a> and <a +href="{@docRoot}reference/android/view/View.html#attr_android:layout_height">{@code +android:layout_height}</a></dt> +<dd>Instead of using specific sizes for the width and height, the <code>"wrap_content"</code> value +specifies that the view should be only as big as needed to fit the contents of the view. If you +were to instead use <code>"fill_parent"</code>, then the {@link android.widget.EditText} +element would fill the screen, because it'd match the size of the parent {@link +android.widget.LinearLayout}. For more information, see the <a +href="{@docRoot}guide/topics/ui/declaring-layout.html">XML Layouts</a> guide.</dd> + +<dt><a +href="{@docRoot}reference/android/widget/TextView.html#attr_android:hint">{@code +android:hint}</a></dt> +<dd>This is a default string to display when the text box is empty. Instead of using a hard-coded +string as the value, the value given in this example refers to a string resource. When you add the +{@code +"@string/edit_message"} value, you’ll see a compiler error because there’s no matching string +resource by that name. You'll fix this in the next section by defining the string +resource.</dd> +</dl> + + + +<h2 id="Strings">Add String Resources</h2> + +<p>When you need to add text in the user interface, you should always specify each string of text in +a resource file. String resources allow you to maintain a single location for all string +values, which makes it easier to find and update text. Externalizing the strings also allows you to +localize your app to different languages by providing alternative definitions for each +string.</p> + +<p>By default, your Android project includes a string resource file at +<code>res/values/strings.xml</code>. Open this file, delete the existing <code>"hello"</code> +string, and add one for the +<code>"edit_message"</code> string used by the {@link android.widget.EditText <EditText>} +element.</p> + +<p>While you’re in this file, also add a string for the button you’ll soon add, called +<code>"button_send"</code>.</p> + +<p>The result for <code>strings.xml</code> looks like this:</p> + +<pre> +<?xml version="1.0" encoding="utf-8"?> +<resources> + <string name="app_name">My First App</string> + <string name="edit_message">Enter a message</string> + <string name="button_send">Send</string> +</resources> +</pre> + +<p>For more information about using string resources to localize your app for several languages, +see the <a +href="{@docRoot}training/basics/supporting-devices/index.html">Supporting Various Devices</a> +class.</p> + + + + +<h2 id="Button">Add a Button</h2> + +<p>Now add a {@link android.widget.Button <Button>} to the layout, immediately following the +{@link android.widget.EditText <EditText>} element:</p> + +<pre> + <Button + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:text="@string/button_send" /> +</pre> + +<p>The height and width are set to <code>"wrap_content"</code> so the button is only as big as +necessary to fit the button's text.</p> + + + +<h2 id="Weight">Make the Input Box Fill in the Screen Width</h2> + +<p>The layout is currently designed so that both the {@link android.widget.EditText} and {@link +android.widget.Button} widgets are only as big as necessary to fit their content, as shown in +figure 2.</p> + +<img src="{@docRoot}images/training/firstapp/edittext_wrap.png" /> +<p class="img-caption"><strong>Figure 2.</strong> The {@link android.widget.EditText} and {@link +android.widget.Button} widgets have their widths set to +<code>"wrap_content"</code>.</p> + +<p>This works fine for the button, but not as well for the text box, because the user might type +something longer and there's extra space left on the screen. So, it'd be nice to fill that width +using the text box. +{@link android.widget.LinearLayout} enables such a design with the <em>weight</em> property, which +you can specify using the <a +href="{@docRoot}reference/android/widget/LinearLayout.LayoutParams.html#weight">{@code +android:layout_weight}</a> attribute.</p> + +<p>The weight value allows you to specify the amount of remaining space each view should consume, +relative to the amount consumed by sibling views, just like the ingredients in a drink recipe: "2 +parts vodka, 1 part coffee liquer" means two-thirds of the drink is vodka. For example, if you give +one view a weight of 2 and another one a weight of 1, the sum is 3, so the first view gets 2/3 of +the remaining space and the second view gets the rest. If you give a third view a weight of 1, +then the first view now gets 1/2 the remaining space, while the remaining two each get 1/4.</p> + +<p>The default weight for all views is 0, so if you specify any weight value +greater than 0 to only one view, then that view fills whatever space remains after each view is +given the space it requires. So, to fill the remaining space with the {@link +android.widget.EditText} element, give it a weight of 1 and leave the button with no weight.</p> + +<pre> + <EditText + android:layout_weight="1" + ... /> +</pre> + +<p>In order to improve the layout efficiency when you specify the weight, you should change the +width of the {@link android.widget.EditText} to be +zero (0dp). Setting the width to zero improves layout performance because using +<code>"wrap_content"</code> as the width requires the system to calculate a width that is +ultimately irrelevant because the weight value requires another width calculation to fill the +remaining space.</p> +<pre> + <EditText + android:layout_weight="1" + android:layout_width="0dp" + ... /> +</pre> + +<p>Figure 3 +shows the result when you assign all weight to the {@link android.widget.EditText} element.</p> + +<img src="{@docRoot}images/training/firstapp/edittext_gravity.png" /> +<p class="img-caption"><strong>Figure 3.</strong> The {@link android.widget.EditText} widget is +given all the layout weight, so fills the remaining space in the {@link +android.widget.LinearLayout}.</p> + +<p>Here’s how your complete layout file should now look:</p> + +<pre> +<?xml version="1.0" encoding="utf-8"?> +<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" + android:layout_width="fill_parent" + android:layout_height="fill_parent" + android:orientation="horizontal"> + <EditText android:id="@+id/edit_message" + android:layout_weight="1" + android:layout_width="0dp" + android:layout_height="wrap_content" + android:hint="@string/edit_message" /> + <Button android:id="@+id/button_send" + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:text="@string/button_send" /> +</LinearLayout> +</pre> + +<p>This layout is applied by the default {@link android.app.Activity} class +that the SDK tools generated when you created the project, so you can now run the app to see the +results:</p> + +<ul> + <li>In Eclipse, click <strong>Run</strong> from the toolbar.</li> + <li>Or from a command line, change directories to the root of your Android project and +execute: +<pre> +ant debug +adb install bin/MyFirstApp-debug.apk +</pre></li> +</ul> + +<p>Continue to the next lesson to learn how you can respond to button presses, read content +from the text field, start another activity, and more.</p> + + + diff --git a/docs/html/training/basics/firstapp/creating-project.jd b/docs/html/training/basics/firstapp/creating-project.jd new file mode 100644 index 0000000..5a89f2e --- /dev/null +++ b/docs/html/training/basics/firstapp/creating-project.jd @@ -0,0 +1,142 @@ +page.title=Creating an Android Project +parent.title=Building Your First App +parent.link=index.html + +trainingnavtop=true +next.title=Running Your App +next.link=running-app.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> + +<ol> + <li><a href="#Eclipse">Create a Project with Eclipse</a></li> + <li><a href="#CommandLine">Create a Project with Command Line Tools</a></li> +</ol> + +<h2>You should also read</h2> + +<ul> + <li><a href="{@docRoot}sdk/installing.html">Installing the +SDK</a></li> + <li><a href="{@docRoot}guide/developing/projects/index.html">Managing Projects</a></li> +</ul> + + +</div> +</div> + +<p>An Android project contains all the files that comprise the source code for your Android +app. The Android SDK tools make it easy to start a new Android project with a set of +default project directories and files.</p> + +<p>This lesson +shows how to create a new project either using Eclipse (with the ADT plugin) or using the +SDK tools from a command line.</p> + +<p class="note"><strong>Note:</strong> You should already have the Android SDK installed, and if +you're using Eclipse, you should have installed the <a +href="{@docRoot}sdk/eclipse-adt.html">ADT plugin</a> as well. If you have not installed +these, see <a href="{@docRoot}sdk/installing.html">Installing the Android SDK</a> and return here +when you've completed the installation.</p> + + +<h2 id="Eclipse">Create a Project with Eclipse</h2> + +<div class="figure" style="width:416px"> +<img src="{@docRoot}images/training/firstapp/adt-firstapp-setup.png" alt="" /> +<p class="img-caption"><strong>Figure 1.</strong> The new project wizard in Eclipse.</p> +</div> + +<ol> + <li>In Eclipse, select <strong>File > New > Project</strong>. +The resulting dialog should have a folder labeled <em>Android</em>. (If you don’t see the +<em>Android</em> folder, +then you have not installed the ADT plugin—see <a +href="{@docRoot}sdk/eclipse-adt.html#installing">Installing the ADT Plugin</a>).</li> + <li>Open the <em>Android</em> folder, select <em>Android Project</em> and click +<strong>Next</strong>.</li> + <li>Enter a project name (such as "MyFirstApp") and click <strong>Next</strong>.</li> + <li>Select a build target. This is the platform version against which you will compile your app. +<p>We recommend that you select the latest version possible. You can still build your app to +support older versions, but setting the build target to the latest version allows you to +easily optimize your app for a great user experience on the latest Android-powered devices.</p> +<p>If you don't see any built targets listed, you need to install some using the Android SDK +Manager tool. See <a href="{@docRoot}sdk/installing.html#AddingComponents">step 4 in the +installing guide</a>.</p> +<p>Click <strong>Next</strong>.</p></li> + <li>Specify other app details, such as the: + <ul> + <li><em>Application Name</em>: The app name that appears to the user. Enter "My First +App".</li> + <li><em>Package Name</em>: The package namespace for your app (following the same +rules as packages in the Java programming language). Your package name +must be unique across all packages installed on the Android system. For this reason, it's important +that you use a standard domain-style package name that’s appropriate to your company or +publisher entity. For +your first app, you can use something like "com.example.myapp." However, you cannot publish your +app using the "com.example" namespace.</li> + <li><em>Create Activity</em>: This is the class name for the primary user activity in your +app (an activity represents a single screen in your app). Enter "MyFirstActivity".</li> + <li><em>Minimum SDK</em>: Select <em>4 (Android 1.6)</em>. + <p>Because this version is lower than the build target selected for the app, a warning +appears, but that's alright. You simply need to be sure that you don't use any APIs that require an +<a href="{@docRoot}guide/appendix/api-levels.html">API level</a> greater than the minimum SDK +version without first using some code to verify the device's system version (you'll see this in some +other classes).</p> + </li> + </ul> + <p>Click <strong>Finish</strong>.</p> + </li> +</ol> + +<p>Your Android project is now set up with some default files and you’re ready to begin +building the app. Continue to the <a href="running-app.html">next lesson</a>.</p> + + + +<h2 id="CommandLine">Create a Project with Command Line Tools</h2> + +<p>If you're not using the Eclipse IDE with the ADT plugin, you can instead create your project +using the SDK tools in a command line:</p> + +<ol> + <li>Change directories into the Android SDK’s <code>tools/</code> path.</li> + <li>Execute: +<pre class="no-pretty-print">android list targets</pre> +<p>This prints a list of the available Android platforms that you’ve downloaded for your SDK. Find +the platform against which you want to compile your app. Make a note of the target id. We +recommend that you select the highest version possible. You can still build your app to +support older versions, but setting the build target to the latest version allows you to optimize +your app for the latest devices.</p> +<p>If you don't see any targets listed, you need to +install some using the Android SDK +Manager tool. See <a href="{@docRoot}sdk/installing.html#AddingComponents">step 4 in the +installing guide</a>.</p></li> + <li>Execute: +<pre class="no-pretty-print"> +android create project --target <target-id> --name MyFirstApp \ +--path <path-to-workspace>/MyFirstApp --activity MyFirstActivity \ +--package com.example.myapp +</pre> +<p>Replace <code><target-id></code> with an id from the list of targets (from the previous step) +and replace +<code><path-to-workspace></code> with the location in which you want to save your Android +projects.</p></li> +</ol> + +<p>Your Android project is now set up with several default configurations and you’re ready to begin +building the app. Continue to the <a href="running-app.html">next lesson</a>.</p> + +<p class="note"><strong>Tip:</strong> Add the <code>platform-tools/</code> as well as the +<code>tools/</code> directory to your <code>PATH</code> environment variable.</p> + + + + diff --git a/docs/html/training/basics/firstapp/index.jd b/docs/html/training/basics/firstapp/index.jd new file mode 100644 index 0000000..a95ed8e --- /dev/null +++ b/docs/html/training/basics/firstapp/index.jd @@ -0,0 +1,64 @@ +page.title=Building Your First App + +trainingnavtop=true +startpage=true +next.title=Creating an Android Project +next.link=creating-project.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>Dependencies and prerequisites</h2> + +<ul> + <li>Android 1.6 or higher</li> + <li><a href="http://developer.android.com/sdk/index.html">Android SDK</a></li> +</ul> + +</div> +</div> + +<p>Welcome to Android application development!</p> + +<p>This class teaches you how to build your first Android app. You’ll learn how to create an Android +project and run a debuggable version of the app. You'll also learn some fundamentals of Android app +design, including how to build a simple user interface and handle user input.</p> + +<p>Before you start this class, be sure that you have your development environment set up. You need +to:</p> +<ol> + <li>Download the Android SDK Starter Package.</li> + <li>Install the ADT plugin for Eclipse (if you’ll use the Eclipse IDE).</li> + <li>Download the latest SDK tools and platforms using the SDK Manager.</li> +</ol> + +<p>If you haven't already done this setup, read <a href="{@docRoot}sdk/installing.html">Installing +the SDK</a>. Once you've finished the setup, you're ready to begin this class.</p> + +<p>This class uses a tutorial format that incrementally builds a small Android app in order to teach +you some fundamental concepts about Android development, so it's important that you follow each +step.</p> + +<p><strong><a href="creating-project.html">Start the first lesson ›</a></strong></p> + + +<h2>Lessons</h2> + +<dl> + <dt><b><a href="creating-project.html">Creating an Android Project</a></b></dt> + <dd>Shows how to create a project for an Android app, which includes a set of default +app files.</dd> + + <dt><b><a href="running-app.html">Running Your Application</a></b></dt> + <dd>Shows how to run your app on an Android-powered device or the Android +emulator.</dd> + + <dt><b><a href="building-ui.html">Building a Simple User Interface</a></b></dt> + <dd>Shows how to create a new user interface using an XML file.</dd> + + <dt><b><a href="starting-activity.html">Starting Another Activity</a></b></dt> + <dd>Shows how to respond to a button press, start another activity, send it some +data, then receive the data in the subsequent activity.</dd> +</dl> diff --git a/docs/html/training/basics/firstapp/running-app.jd b/docs/html/training/basics/firstapp/running-app.jd new file mode 100644 index 0000000..2398fa0 --- /dev/null +++ b/docs/html/training/basics/firstapp/running-app.jd @@ -0,0 +1,178 @@ +page.title=Running Your App +parent.title=Building Your First App +parent.link=index.html + +trainingnavtop=true +previous.title=Creating a Project +previous.link=creating-project.html +next.title=Building a Simple User Interface +next.link=building-ui.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> + +<ol> + <li><a href="#RealDevice">Run on a Real Device</a></li> + <li><a href="#Emulator">Run on the Emulator</a></li> +</ol> + +<h2>You should also read</h2> + +<ul> + <li><a href="{@docRoot}guide/developing/device.html">Using Hardware Devices</a></li> + <li><a href="{@docRoot}guide/developing/devices/index.html">Managing Virtual Devices</a></li> + <li><a href="{@docRoot}guide/developing/projects/index.html">Managing Projects</a></li> +</ul> + + +</div> +</div> + + +<p>If you followed the <a href="{@docRoot}creating-project.html">previous lesson</a> to create an +Android project, it includes a default set of "Hello World" source files that allow you to +run the app right away.</p> + +<p>How you run your app depends on two things: whether you have a real Android-powered device and +whether you’re using Eclipse. This lesson shows you how to install and run your app on a +real device and on the Android emulator, and in both cases with either Eclipse or the command line +tools.</p> + +<p>Before you run your app, you should be aware of a few directories and files in the Android +project:</p> + +<dl> + <dt><code>AndroidManifest.xml</code></dt> + <dd>This manifest file describes the fundamental characteristics of the app and defines each of +its components. You'll learn about various declarations in this file as you read more training +classes.</dd> + <dt><code>src/</code></dt> + <dd>Directory for your app's main source files. By default, it includes an {@link +android.app.Activity} class that runs when your app is launched using the app icon.</dd> + <dt><code>res/</code></dt> + <dd>Contains several sub-directories for app resources. Here are just a few: + <dl style="margin-top:1em"> + <dt><code>drawable-hdpi/</code></dt> + <dd>Directory for drawable objects (such as bitmaps) that are designed for high-density +(hdpi) screens. Other drawable directories contain assets designed for other screen densities.</dd> + <dt><code>layout/</code></dt> + <dd>Directory for files that define your app's user interface.</dd> + <dt><code>values/</code></dt> + <dd>Directory for other various XML files that contain a collection of resources, such as +string and color definitions.</dd> + </dl> + </dd> +</dl> + +<p>When you build and run the default Android project, the default {@link android.app.Activity} +class in the <code>src/</code> directory starts and loads a layout file from the +<code>layout/</code> directory, which includes a "Hello World" message. Not real exciting, but it's +important that you understand how to build and run your app before adding real functionality to +the app.</p> + + + +<h2 id="RealDevice">Run on a Real Device</h2> + +<p>Whether you’re using Eclipse or the command line, you need to:</p> + +<ol> + <li>Plug in your Android-powered device to your machine with a USB cable. +If you’re developing on Windows, you might need to install the appropriate USB driver for your +device. For help installing drivers, see the <a href=”{@docRoot}sdk/oem-usb.html”>OEM USB +Drivers</a> document.</li> + <li>Ensure that <strong>USB debugging</strong> is enabled in the device Settings (open Settings +and navitage to <strong>Applications > Development</strong> on most devices, or select +<strong>Developer options</strong> on Android 4.0 and higher).</li> +</ol> + +<p>To run the app from Eclipse, open one of your project's files and click +<strong>Run</strong> from the toolbar. Eclipse installs the app on your connected device and starts +it.</p> + + +<p>Or to run your app from a command line:</p> + +<ol> + <li>Change directories to the root of your Android project and execute: +<pre class="no-pretty-print">ant debug</pre></li> + <li>Make sure the Android SDK <code>platform-tools/</code> directory is included in your +<code>PATH</code> environment variable, then execute: +<pre class="no-pretty-print">adb install bin/MyFirstApp-debug.apk</pre></li> + <li>On your device, locate <em>MyFirstActivity</em> and open it.</li> +</ol> + +<p>To start adding stuff to the app, continue to the <a href="building-ui.html">next +lesson</a>.</p> + + + +<h2 id="Emulator">Run on the Emulator</h2> + +<p>Whether you’re using Eclipse or the command line, you need to first create an <a +href="{@docRoot}guide/developing/devices/index.html">Android Virtual +Device</a> (AVD). An AVD is a +device configuration for the Android emulator that allows you to model +different device configurations.</p> + +<div class="figure" style="width:457px"> + <img src="{@docRoot}images/screens_support/avds-config.png" alt="" /> + <p class="img-caption"><strong>Figure 1.</strong> The AVD Manager showing a few virtual +devices.</p> +</div> + +<p>To create an AVD:</p> +<ol> + <li>Launch the Android Virtual Device Manager: + <ol type="a"> + <li>In Eclipse, select <strong>Window > AVD Manager</strong>, or click the <em>AVD +Manager</em> icon in the Eclipse toolbar.</li> + <li>From the command line, change directories to <code><sdk>/tools/</code> and execute: +<pre class="no-pretty-print">./android avd</pre></li> + </ol> + </li> + <li>In the <em>Android Virtual Device Device Manager</em> panel, click <strong>New</strong>.</li> + <li>Fill in the details for the AVD. +Give it a name, a platform target, an SD card size, and a skin (HVGA is default).</li> + <li>Click <strong>Create AVD</strong>.</li> + <li>Select the new AVD from the <em>Android Virtual Device Manager</em> and click +<strong>Start</strong>.</li> + <li>After the emulator boots up, unlock the emulator screen.</li> +</ol> + +<p>To run the app from Eclipse, open one of your project's files and click +<strong>Run</strong> from the toolbar. Eclipse installs the app on your AVD and starts it.</p> + + +<p>Or to run your app from the command line:</p> + +<ol> + <li>Change directories to the root of your Android project and execute: +<pre class="no-pretty-print">ant debug</pre></li> + <li>Make sure the Android SDK <code>platform-tools/</code> directory is included in your +<code>PATH</code> environment +variable, then execute: +<pre class="no-pretty-print">adb install bin/MyFirstApp-debug.apk</pre></li> + <li>On the emulator, locate <em>MyFirstActivity</em> and open it.</li> +</ol> + + +<p>To start adding stuff to the app, continue to the <a href="building-ui.html">next +lesson</a>.</p> + + + + + + + + + + + diff --git a/docs/html/training/basics/firstapp/starting-activity.jd b/docs/html/training/basics/firstapp/starting-activity.jd new file mode 100644 index 0000000..16a6fd8 --- /dev/null +++ b/docs/html/training/basics/firstapp/starting-activity.jd @@ -0,0 +1,308 @@ +page.title=Starting Another Activity +parent.title=Building Your First App +parent.link=index.html + +trainingnavtop=true +previous.title=Building a Simpler User Interface +previous.link=building-ui.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> + +<ol> + <li><a href="#RespondToButton">Respond to the Send Button</a></li> + <li><a href="#BuildIntent">Build an Intent</a></li> + <li><a href="#StartActivity">Start the Second Activity</a></li> + <li><a href="#CreateActivity">Create the Second Activity</a> + <ol> + <li><a href="#AddToManifest">Add it to the manifest</a></li> + </ol> + </li> + <li><a href="#ReceiveIntent">Receive the Intent</a></li> + <li><a href="#DisplayMessage">Display the Message</a></li> +</ol> + +<h2>You should also read</h2> + +<ul> + <li><a href="{@docRoot}sdk/installing.html">Installing the +SDK</a></li> +</ul> + + +</div> +</div> + + + +<p>After completing the <a href="building-ui.html">previous lesson</a>, you have an app that +shows an activity (a single screen) with a text box and a button. In this lesson, you’ll add some +code to <code>MyFirstActivity</code> that +starts a new activity when the user selects the Send button.</p> + + +<h2 id="RespondToButton">Respond to the Send Button</h2> + +<p>To respond to the button's on-click event, open the <code>main.xml</code> layout file and add the +<a +href="{@docRoot}reference/android/view/View.html#attr_android:onClick">{@code android:onClick}</a> +attribute to the {@link android.widget.Button <Button>} element:</p> + +<pre> +<Button android:id="@+id/button_send" + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:text="@string/button_send" + android:onClick="sendMessage" /> +</pre> + +<p>The <a +href="{@docRoot}reference/android/view/View.html#attr_android:onClick">{@code +android:onClick}</a> attribute’s value, <code>sendMessage</code>, is the name of a method in your +activity that you want to call when the user selects the button.</p> + +<p>Add the corresponding method inside the <code>MyFirstActivity</code> class:</p> + +<pre> +/** Called when the user selects the Send button */ +public void sendMessage(View view) { + // Do something in response to button +} +</pre> + +<p class="note"><strong>Tip:</strong> In Eclipse, press Ctrl + Shift + O to import missing classes +(Cmd + Shift + O on Mac).</p> + +<p>Note that, in order for the system to match this method to the method name given to <a +href="{@docRoot}reference/android/view/View.html#attr_android:onClick">{@code android:onClick}</a>, +the signature must be exactly as shown. Specifically, the method must:</p> + +<ul> +<li>Be public</li> +<li>Have a void return value</li> +<li>Have a {@link android.view.View} as the only parameter (this will be the {@link +android.view.View} that was clicked)</li> +</ul> + +<p>Next, you’ll fill in this method to read the contents of the text box and deliver that text to +another activity.</p> + + + +<h2 id="BuildIntent">Build an Intent</h2> + +<p>An {@link android.content.Intent} is an object that provides runtime binding between separate +components (such as two activities). The {@link android.content.Intent} represents an +app’s "intent to do something." You can use an {@link android.content.Intent} for a wide +variety of tasks, but most often they’re used to start another activity.</p> + +<p>Inside the {@code sendMessage()} method, create an {@link android.content.Intent} to start +an activity called {@code DisplayMessageActvity}:</p> + +<pre> +Intent intent = new Intent(this, DisplayMessageActivity.class); +</pre> + +<p>The constructor used here takes two parameters:</p> +<ul> + <li>A {@link +android.content.Context} as its first parameter ({@code this} is used because the {@link +android.app.Activity} class is a subclass of {@link android.content.Context}) + <li>The {@link java.lang.Class} of the app component to which the system should deliver +the {@link android.content.Intent} (in this case, the activity that should be started) +</ul> + +<div class="sidebox-wrapper"> +<div class="sidebox"> + <h3>Sending an intent to other apps</h3> + <p>The intent created in this lesson is what's considered an <em>explicit intent</em>, because the +{@link android.content.Intent} +specifies the exact app component to which the intent should be given. However, intents +can also be <em>implicit</em>, in which case the {@link android.content.Intent} does not specify +the desired component, but allows any app installed on the device to respond to the intent +as long as it satisfies the meta-data specifications for the action that's specified in various +{@link android.content.Intent} parameters. For more informations, see the class about <a +href="{@docRoot}training/intents/index.html">Interacting with Other Apps</a>.</p> +</div> +</div> + +<p class="note"><strong>Note:</strong> The reference to {@code DisplayMessageActivity} +will raise an error if you’re using an IDE such as Eclipse because the class doesn’t exist yet. +Ignore the error for now; you’ll create the class soon.</p> + +<p>An intent not only allows you to start another activity, but can carry a bundle of data to the +activity as well. So, use {@link android.app.Activity#findViewById findViewById()} to get the +{@link android.widget.EditText} element and add its message to the intent:</p> + +<pre> +Intent intent = new Intent(this, DisplayMessageActivity.class); +EditText editText = (EditText) findViewById(R.id.edit_message); +String message = editText.getText().toString(); +intent.putExtra(EXTRA_MESSAGE, message); +</pre> + +<p>An {@link android.content.Intent} can carry a collection of various data types as key-value +pairs called <em>extras</em>. The {@link android.content.Intent#putExtra putExtra()} method takes a +string as the key and the value in the second parameter.</p> + +<p>In order for the next activity to query the extra data, you should define your keys using a +public constant. So add the {@code EXTRA_MESSAGE} definition to the top of the {@code +MyFirstActivity} class:</p> + +<pre> +public class MyFirstActivity extends Activity { + public final static String EXTRA_MESSAGE = "com.example.myapp.MESSAGE"; + ... +} +</pre> + +<p>It's generally a good practice to define keys for extras with your app's package name as a prefix +to ensure it's unique, in case your app interacts with other apps.</p> + + +<h2 id="StartActivity">Start the Second Activity</h2> + +<p>To start an activity, you simply need to call {@link android.app.Activity#startActivity +startActivity()} and pass it your {@link android.content.Intent}.</p> + +<p>The system receives this call and starts an instance of the {@link android.app.Activity} +specified by the {@link android.content.Intent}.</p> + +<p>With this method included, the complete {@code sendMessage()} method that's invoked by the Send +button now looks like this:</p> + +<pre> +/** Called when the user selects the Send button */ +public void sendMessage(View view) { + Intent intent = new Intent(this, DisplayMessageActivity.class); + EditText editText = (EditText) findViewById(R.id.edit_message); + String message = editText.getText().toString(); + intent.putExtra(EXTRA_MESSAGE, message); + startActivity(intent); +} +</pre> + +<p>Now you need to create the {@code DisplayMessageActivity} class in order for this to +work.</p> + + + +<h2 id="CreateActivity">Create the Second Activity</h2> + +<p>In your project, create a new class file under the <code>src/<package-name>/</code> +directory called <code>DisplayMessageActivity.java</code>.</p> + +<p class="note"><strong>Tip:</strong> In Eclipse, right-click the package name under the +<code>src/</code> directory and select <strong>New > Class</strong>. +Enter "DisplayMessageActivity" for the name and {@code android.app.Activity} for the superclass.</p> + +<p>Inside the class, add the {@link android.app.Activity#onCreate onCreate()} callback method:</p> + +<pre> +public class DisplayMessageActivity extends Activity { + @Override + public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + } +} +</pre> + +<p>All subclasses of {@link android.app.Activity} must implement the {@link +android.app.Activity#onCreate onCreate()} method. The system calls this when creating a new +instance of the activity. It is where you must define the activity layout and where you should +initialize essential activity components.</p> + + + +<h3 id="AddToManifest">Add it to the manifest</h3> + +<p>You must declare all activities in your manifest file, <code>AndroidManifest.xml</code>, using an +<a +href="{@docRoot}guide/topics/manifest/activity-element.html">{@code <activity>}</a> element.</p> + +<p>Because {@code DisplayMessageActivity} is invoked using an explicit intent, it does not require +any intent filters (such as those you can see in the manifest for <code>MyFirstActivity</code>). So +the declaration for <code>DisplayMessageActivity</code> can be simply one line of code inside the <a +href="{@docRoot}guide/topics/manifest/application-element.html">{@code <application>}</a> +element:</p> + +<pre> +<application ... > + <activity android:name="com.example.myapp.DisplayMessageActivity" /> + ... +</application> +</pre> + +<p>The app is now runnable because the {@link android.content.Intent} in the +first activity now resolves to the {@code DisplayMessageActivity} class. If you run the app now, +pressing the Send button starts the +second activity, but it doesn't show anything yet.</p> + + +<h2 id="ReceiveIntent">Receive the Intent</h2> + +<p>Every {@link android.app.Activity} is invoked by an {@link android.content.Intent}, regardless of +how the user navigated there. You can get the {@link android.content.Intent} that started your +activity by calling {@link android.app.Activity#getIntent()} and the retrieve data contained +within it.</p> + +<p>In the {@code DisplayMessageActivity} class’s {@link android.app.Activity#onCreate onCreate()} +method, get the intent and extract the message delivered by {@code MyFirstActivity}:</p> + +<pre> +Intent intent = getIntent(); +String message = intent.getStringExtra(MyFirstActivity.EXTRA_MESSAGE); +</pre> + + + +<h2 id="DisplayMessage">Display the Message</h2> + +<p>To show the message on the screen, create a {@link android.widget.TextView} widget and set the +text using {@link android.widget.TextView#setText setText()}. Then add the {@link +android.widget.TextView} as the root view of the activity’s layout by passing it to {@link +android.app.Activity#setContentView setContentView()}.</p> + +<p>The complete {@link android.app.Activity#onCreate onCreate()} method for {@code +DisplayMessageActivity} now looks like this:</p> + +<pre> +@Override +public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + + // Get the message from the intent + Intent intent = getIntent(); + String message = intent.getStringExtra(MyFirstActivity.EXTRA_MESSAGE); + + // Create the text view + TextView textView = new TextView(this); + textView.setTextSize(40); + textView.setText(message); + + setContentView(textView); +} +</pre> + +<p>You can now run the app, type a message in the text box, press Send, and view the message on the +second activity.</p> + +<img src="{@docRoot}images/training/firstapp/firstapp.png" /> +<p class="img-caption"><strong>Figure 1.</strong> Both activities in the final app, running +on Android 4.0. + +<p>That's it, you've built your first Android app!</p> + +<p>To learn more about building Android apps, continue to follow the +basic training classes. The next class is <a +href="{@docRoot}training/activity-lifecycle/index.html">Managing the Activity Lifecycle</a>.</p> + + + + diff --git a/docs/html/training/basics/intents/filters.jd b/docs/html/training/basics/intents/filters.jd new file mode 100644 index 0000000..0090c98 --- /dev/null +++ b/docs/html/training/basics/intents/filters.jd @@ -0,0 +1,244 @@ +page.title=Allowing Other Apps to Start Your Activity +parent.title=Interacting with Other Apps +parent.link=index.html + +trainingnavtop=true +previous.title=Getting a Result from an Activity +previous.link=result.html + +@jd:body + +<div id="tb-wrapper"> + <div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#AddIntentFilter">Add an Intent Filter</a></li> + <li><a href="#HandleIntent">Handle the Intent in Your Activity</a></li> + <li><a href="#ReturnResult">Return a Result</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/sharing/index.html">Sharing Content</a></li> +</ul> + </div> +</div> + +<p>The previous two lessons focused on one side of the story: starting another app's activity from +your app. But if your app can perform an action that might be useful to another app, +your app should be prepared to respond to action requests from other apps. For instance, if you +build a social app that can share messages or photos with the user's friends, it's in your best +interest to support the {@link android.content.Intent#ACTION_SEND} intent so users can initiate a +"share" action from another app and launch your app to perform the action.</p> + +<p>To allow other apps to start your activity, you need to add an <a +href="{@docRoot}guide/topics/manifest/intent-filter-element.html">{@code <intent-filter>}</a> +element in your manifest file for the corresponding <a +href="{@docRoot}guide/topics/manifest/activity-element.html">{@code <activity>}</a> element.</p> + +<p>When your app is installed on a device, the system identifies your intent +filters and adds the information to an internal catalog of intents supported by all installed apps. +When an app calls {@link android.app.Activity#startActivity +startActivity()} or {@link android.app.Activity#startActivityForResult startActivityForResult()}, +with an implicit intent, the system finds which activity (or activities) can respond to the +intent.</p> + + + +<h2 id="AddIntentFilter">Add an Intent Filter</h2> + +<p>In order to properly define which intents your activity can handle, each intent filter you add +should be as specific as possible in terms of the type of action and data the activity +accepts.</p> + +<p>The system may send a given {@link android.content.Intent} to an activity if that activity has +an intent filter fulfills the following criteria of the {@link android.content.Intent} object:</p> + +<dl> + <dt>Action</dt> + <dd>A string naming the action to perform. Usually one of the platform-defined values such +as {@link android.content.Intent#ACTION_SEND} or {@link android.content.Intent#ACTION_VIEW}. + <p>Specify this in your intent filter with the <a +href="{@docRoot}guide/topics/manifest/action-element.html">{@code <action>}</a> element. +The value you specify in this element must be the full string name for the action, instead of the +API constant (see the examples below).</p></dd> + + <dt>Data</dt> + <dd>A description of the data associated with the intent. + <p>Specify this in your intent filter with the <a +href="{@docRoot}guide/topics/manifest/data-element.html">{@code <data>}</a> element. Using one +or more attributes in this element, you can specify just the MIME type, just a URI prefix, +just a URI scheme, or a combination of these and others that indicate the data type +accepted.</p> + <p class="note"><strong>Note:</strong> If you don't need to declare specifics about the data +{@link android.net.Uri} (such as when your activity handles to other kind of "extra" data, instead +of a URI), you should specify only the {@code android:mimeType} attribute to declare the type of +data your activity handles, such as {@code text/plain} or {@code image/jpeg}.</p> +</dd> + <dt>Category</dt> + <dd>Provides an additional way to characterize the activity handling the intent, usually related +to the user gesture or location from which it's started. There are several different categories +supported by the system, but most are rarely used. However, all implicit intents are defined with +{@link android.content.Intent#CATEGORY_DEFAULT} by default. + <p>Specify this in your intent filter with the <a +href="{@docRoot}guide/topics/manifest/category-element.html">{@code <category>}</a> +element.</p></dd> +</dl> + +<p>In your intent filter, you can declare which criteria your activity accepts +by declaring each of them with corresponding XML elements nested in the <a +href="{@docRoot}guide/topics/manifest/intent-filter-element.html">{@code <intent-filter>}</a> +element.</p> + +<p>For example, here's an activity with an intent filter that handles the {@link +android.content.Intent#ACTION_SEND} intent when the data type is either text or an image:</p> + +<pre> +<activity android:name="ShareActivity"> + <intent-filter> + <action android:name="android.intent.action.SEND"/> + <category android:name="android.intent.category.DEFAULT"/> + <data android:mimeType="text/plain"/> + <data android:mimeType="image/*"/> + </intent-filter> +</activity> +</pre> + +<p>Each incoming intent specifies only one action and one data type, but it's OK to declare multiple +instances of the <a href="{@docRoot}guide/topics/manifest/action-element.html">{@code +<action>}</a>, <a href="{@docRoot}guide/topics/manifest/category-element.html">{@code +<category>}</a>, and <a href="{@docRoot}guide/topics/manifest/data-element.html">{@code +<data>}</a> elements in each +<a href="{@docRoot}guide/topics/manifest/intent-filter-element.html">{@code +<intent-filter>}</a>.</p> + +<p>If any two pairs of action and data are mutually exclusive in +their behaviors, you should create separate intent filters to specify which actions are acceptable +when paired with which data types.</p> + +<p>For example, suppose your activity handles both text and images for both the {@link +android.content.Intent#ACTION_SEND} and {@link +android.content.Intent#ACTION_SENDTO} intents. In this case, you must define two separate +intent filters for the two actions because a {@link +android.content.Intent#ACTION_SENDTO} intent must use the data {@link android.net.Uri} to specify +the recipient's address using the {@code send} or {@code sendto} URI scheme. For example:</p> + +<pre> +<activity android:name="ShareActivity"> + <!-- filter for sending text; accepts SENDTO action with sms URI schemes --> + <intent-filter> + <action android:name="android.intent.action.SENDTO"/> + <category android:name="android.intent.category.DEFAULT"/> + <data android:scheme="sms" /> + <data android:scheme="smsto" /> + </intent-filter> + <!-- filter for sending text or images; accepts SEND action and text or image data --> + <intent-filter> + <action android:name="android.intent.action.SEND"/> + <category android:name="android.intent.category.DEFAULT"/> + <data android:mimeType="image/*"/> + <data android:mimeType="text/plain"/> + </intent-filter> +</activity> +</pre> + +<p class="note"><strong>Note:</strong> In order to receive implicit intents, you must include the +{@link android.content.Intent#CATEGORY_DEFAULT} category in the intent filter. The methods {@link +android.app.Activity#startActivity startActivity()} and {@link +android.app.Activity#startActivityForResult startActivityForResult()} treat all intents as if they +contained the {@link android.content.Intent#CATEGORY_DEFAULT} category. If you do not declare it, no +implicit intents will resolve to your activity.</p> + +<p>For more information about sending and receiving {@link android.content.Intent#ACTION_SEND} +intents that perform social sharing behaviors, see the lesson about <a +href="{@docRoot}training/sharing/receive.html">Receiving Content from Other Apps</a>.</p> + + +<h2 id="HandleIntent">Handle the Intent in Your Activity</h2> + +<p>In order to decide what action to take in your activity, you can read the {@link +android.content.Intent} that was used to start it.</p> + +<p>As your activity starts, call {@link android.app.Activity#getIntent()} to retrieve the +{@link android.content.Intent} that started the activity. You can do so at any time during the +lifecycle of the activity, but you should generally do so during early callbacks such as +{@link android.app.Activity#onCreate onCreate()} or {@link android.app.Activity#onStart()}.</p> + +<p>For example:</p> + +<pre> +@Override +protected void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + + setContentView(R.layout.main); + + // Get the intent that started this activity + Intent intent = getIntent(); + Uri data = intent.getData(); + + // Figure out what to do based on the intent type + if (intent.getType().indexOf("image/") != -1) { + // Handle intents with image data ... + } else if (intent.getType().equals("text/plain")) { + // Handle intents with text ... + } +} +</pre> + + +<h2 id="ReturnResult">Return a Result</h2> + +<p>If you want to return a result to the activity that invoked yours, simply call {@link +android.app.Activity#setResult(int,Intent) setResult()} to specify the result code and result {@link +android.content.Intent}. When your operation is done and the user should return to the original +activity, call {@link android.app.Activity#finish()} to close (and destroy) your activity. For +example:</p> + +<pre> +// Create intent to deliver some kind of result data +Intent result = new Intent("com.example.RESULT_ACTION", Uri.parse("content://result_uri"); +setResult(Activity.RESULT_OK, result); +finish(); +</pre> + +<p>You must always specify a result code with the result. Generally, it's either {@link +android.app.Activity#RESULT_OK} or {@link android.app.Activity#RESULT_CANCELED}. You can then +provide additional data with an {@link android.content.Intent}, as necessary.</p> + +<p class="note"><strong>Note:</strong> The result is set to {@link +android.app.Activity#RESULT_CANCELED} by default. So, if the user presses the <em>Back</em> +button before completing the action and before you set the result, the original activity receives +the "canceled" result.</p> + +<p>If you simply need to return an integer that indicates one of several result options, you can set +the result code to any value higher than 0. If you use the result code to deliver an integer and you +have no need to include the {@link android.content.Intent}, you can call {@link +android.app.Activity#setResult(int) setResult()} and pass only a result code. For example:</p> + +<pre> +setResult(RESULT_COLOR_RED); +finish(); +</pre> + +<p>In this case, there might be only a handful of possible results, so the result code is a locally +defined integer (greater than 0). This works well when you're returning a result to an activity +in your own app, because the activity that receives the result can reference the public +constant to determine the value of the result code.</p> + +<p class="note"><strong>Note:</strong> There's no need to check whether your activity was started +with {@link +android.app.Activity#startActivity startActivity()} or {@link +android.app.Activity#startActivityForResult startActivityForResult()}. Simply call {@link +android.app.Activity#setResult(int,Intent) setResult()} if the intent that started your activity +might expect a result. If the originating activity had called {@link +android.app.Activity#startActivityForResult startActivityForResult()}, then the system delivers it +the result you supply to {@link android.app.Activity#setResult(int,Intent) setResult()}; otherwise, +the result is ignored.</p> + + + + + + diff --git a/docs/html/training/basics/intents/index.jd b/docs/html/training/basics/intents/index.jd new file mode 100644 index 0000000..c661d98 --- /dev/null +++ b/docs/html/training/basics/intents/index.jd @@ -0,0 +1,64 @@ +page.title=Interacting with Other Apps + +trainingnavtop=true +startpage=true +next.title=Sending the User to Another App +next.link=sending.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>Dependencies and prerequisites</h2> +<ul> + <li>Basic understanding of the Activity lifecycle (see <a +href="{@docRoot}training/basics/activity-lifecycle/index.html">Managing the Activity +Lifecycle</a>)</li> +</ul> + + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/sharing/index.html">Sharing Content</a></li> + <li><a +href="http://android-developers.blogspot.com/2009/11/integrating-application-with-intents.html"> +Integrating Application with Intents (blog post)</a></li> + <li><a href="{@docRoot}guide/topics/intents/intents-filters.html">Intents and Intent +Filters</a></li> +</ul> + +</div> +</div> + +<p>An Android app typically has several <a +href="{@docRoot}guide/topics/fundamentals/activities.html">activities</a>. Each activity displays a +user interface that allows the user to perform a specific task (such as view a map or take a photo). +To take the user from one activity to another, your app must use an {@link +android.content.Intent} to define your app's "intent" to do something. When you pass an +{@link android.content.Intent} to the system with a method such as {@link +android.app.Activity#startActivity startActivity()}, the system uses the {@link +android.content.Intent} to identify and start the appropriate app component. Using intents even +allows your app to start an activity that is contained in a separate app.</p> + +<p>An {@link android.content.Intent} can be <em>explicit</em> in order to start a specific component +(a specific {@link android.app.Activity} instance) or <em>implicit</em> in order to start any +component that can handle the intended action (such as "capture a photo").</p> + +<p>This class shows you how to use an {@link android.content.Intent} to perform some basic +interactions with other apps, such as start another app, receive a result from that app, and +make your app able to respond to intents from other apps.</p> + +<h2>Lessons</h2> + +<dl> + <dt><b><a href="sending.html">Sending the User to Another App</a></b></dt> + <dd>Shows how you can create implicit intents to launch other apps that can perform an +action.</dd> + <dt><b><a href="result.html">Getting a Result from an Activity</a></b></dt> + <dd>Shows how to start another activity and receive a result from the activity.</dd> + <dt><b><a href="filters.html">Allowing Other Apps to Start Your Activity</a></b></dt> + <dd>Shows how to make activities in your app open for use by other apps by defining +intent filters that declare the implicit intents your app accepts.</dd> +</dl> + diff --git a/docs/html/training/basics/intents/result.jd b/docs/html/training/basics/intents/result.jd new file mode 100644 index 0000000..0086913 --- /dev/null +++ b/docs/html/training/basics/intents/result.jd @@ -0,0 +1,182 @@ +page.title=Getting a Result from an Activity +parent.title=Interacting with Other Apps +parent.link=index.html + +trainingnavtop=true +previous.title=Sending the User to Another App +previous.link=sending.html +next.title=Allowing Other Apps to Start Your Activity +next.link=filters.html + +@jd:body + +<div id="tb-wrapper"> + <div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#StartActivity">Start the Activity</a></li> + <li><a href="#ReceiveResult">Receive the Result</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/sharing/index.html">Sharing Content</a></li> +</ul> + + </div> +</div> + +<p>Starting another activity doesn't have to be one-way. You can also start another activity and +receive a result back. To receive a result, call {@link android.app.Activity#startActivityForResult +startActivityForResult()} (instead of {@link android.app.Activity#startActivity +startActivity()}).</p> + +<p>For example, your app can start a camera app and receive the captured photo as a result. Or, you +might start the People app in order for the user to select a +contact and you'll receive the contact details as a result.</p> + +<p>Of course, the activity that responds must be designed to return a result. When it does, it +sends the result as another {@link android.content.Intent} object. Your activity receives it in +the {@link android.app.Activity#onActivityResult onActivityResult()} callback.</p> + +<p class="note"><strong>Note:</strong> You can use explicit or implicit intents when you call +{@link android.app.Activity#startActivityForResult startActivityForResult()}. When starting one of +your own activities to receive a result, you should use an explicit intent to ensure that you +receive the expected result.</p> + + +<h2 id="StartActivity">Start the Activity</h2> + +<p>There's nothing special about the {@link android.content.Intent} object you use when starting +an activity for a result, but you do need to pass an additional integer argument to the {@link +android.app.Activity#startActivityForResult startActivityForResult()} method.</p> + +<p>The integer argument is a "request code" that identifies your request. When you receive the +result {@link android.content.Intent}, the callback provides the same request code so that your +app can properly identify the result and determine how to handle it.</p> + +<p>For example, here's how to start an activity that allows the user to pick a contact:</p> + +<pre> +static final int PICK_CONTACT_REQUEST = 1; // The request code +... +private void pickContact() { + Intent pickContactIntent = new Intent(Intent.ACTION_PICK, new Uri("content://contacts")); + pickContactIntent.setType(Phone.CONTENT_TYPE); // Show user only contacts w/ phone numbers + startActivityForResult(pickContactIntent, PICK_CONTACT_REQUEST); +} +</pre> + + +<h2 id="ReceiveResult">Receive the Result</h2> + +<p>When the user is done with the subsequent activity and returns, the system calls your activity's +{@link android.app.Activity#onActivityResult onActivityResult()} method. This method includes three +arguments:</p> + +<ul> + <li>The request code you passed to {@link +android.app.Activity#startActivityForResult startActivityForResult()}.</li> + <li>A result code specified by the second activity. This is either {@link +android.app.Activity#RESULT_OK} if the operation was successful or {@link +android.app.Activity#RESULT_CANCELED} if the user backed out or the operation failed for some +reason.</li> + <li>An {@link android.content.Intent} that carries the result data.</li> +</ul> + +<p>For example, here's how you can handle the result for the "pick a contact" intent:</p> + +<pre> +@Override +protected void onActivityResult(int requestCode, int resultCode, Intent data) { + // Check which request we're responding to + if (requestCode == PICK_CONTACT_REQUEST) { + // Make sure the request was successful + if (resultCode == RESULT_OK) { + // The user picked a contact. + // The Intent's data Uri identifies which contact was selected. + + // Do something with the contact here (bigger example below) + } + } +} +</pre> + +<p>In this example, the result {@link android.content.Intent} returned by +Android's Contacts or People app provides a content {@link android.net.Uri} that identifies the +contact the user selected.</p> + +<p>In order to successfully handle the result, you must understand what the format of the result +{@link android.content.Intent} will be. Doing so is easy when the activity returning a result is +one of your own activities. Apps included with the Android platform offer their own APIs that +you can count on for specific result data. For instance, the People app (Contacts app on some older +versions) always returns a result with the content URI that identifies the selected contact, and the +Camera app returns a {@link android.graphics.Bitmap} in the {@code "data"} extra (see the class +about <a href="{@docRoot}training/camera/index.html">Capturing Photos</a>).</p> + + +<h4>Bonus: Read the contact data</h4> + +<p>The code above showing how to get a result from the People app doesn't go into +details about how to actually read the data from the result, because it requires more advanced +discussion about <a href="{@docRoot}guide/topics/providers/content-providers.html">content +providers</a>. However, if you're curious, here's some more code that shows how to query the +result data to get the phone number from the selected contact:</p> + +<pre> +@Override +protected void onActivityResult(int requestCode, int resultCode, Intent data) { + // Check which request it is that we're responding to + if (requestCode == PICK_CONTACT_REQUEST) { + // Make sure the request was successful + if (resultCode == RESULT_OK) { + // Get the URI that points to the selected contact + Uri contactUri = data.getData(); + // We only need the NUMBER column, because there will be only one row in the result + String[] projection = {Phone.NUMBER}; + + // Perform the query on the contact to get the NUMBER column + // We don't need a selection or sort order (there's only one result for the given URI) + // CAUTION: The query() method should be called from a separate thread to avoid blocking + // your app's UI thread. (For simplicity of the sample, this code doesn't do that.) + // Consider using {@link android.content.CursorLoader} to perform the query. + Cursor cursor = getContentResolver() + .query(contactUri, projection, null, null, null); + cursor.moveToFirst(); + + // Retrieve the phone number from the NUMBER column + int column = cursor.getColumnIndex(Phone.NUMBER); + String number = cursor.getString(column); + + // Do something with the phone number... + } + } +} +</pre> + +<p class="note"><strong>Note:</strong> Before Android 2.3 (API level 9), performing a query +on the {@link android.provider.ContactsContract.Contacts Contacts Provider} (like the one shown +above) requires that your app declare the {@link +android.Manifest.permission#READ_CONTACTS} permission (see <a +href="{@docRoot}guide/topics/security/security.html">Security and Permissions</a>). However, +beginning with Android 2.3, the Contacts/People app grants your app a temporary +permission to read from the Contacts Provider when it returns you a result. The temporary permission +applies only to the specific contact requested, so you cannot query a contact other than the one +specified by the intent's {@link android.net.Uri}, unless you do declare the {@link +android.Manifest.permission#READ_CONTACTS} permission.</p> + + + + + + + + + + + + + + + diff --git a/docs/html/training/basics/intents/sending.jd b/docs/html/training/basics/intents/sending.jd new file mode 100644 index 0000000..a71c8f9 --- /dev/null +++ b/docs/html/training/basics/intents/sending.jd @@ -0,0 +1,211 @@ +page.title=Sending the User to Another App +parent.title=Interacting with Other Apps +parent.link=index.html + +trainingnavtop=true +next.title=Getting a Result from an Activity +next.link=result.html + +@jd:body + + +<div id="tb-wrapper"> + <div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#Build">Build an Implicit Intent</a></li> + <li><a href="#Verify">Verify There is an App to Receive the Intent</a></li> + <li><a href="#StartActivity">Start an Activity with the Intent</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/sharing/index.html">Sharing Content</a></li> +</ul> + + </div> +</div> + +<p>One of Android's most important features is an app's ability to send the user to another app +based on an "action" it would like to perform. For example, if +your app has the address of a business that you'd like to show on a map, you don't have to build +an activity in your app that shows a map. Instead, you can send a out a request to view the address +using an {@link android.content.Intent}. The Android system then starts an app that's able to view +the address on a map.</p> + +<p>As shown in the first class, <a href="{@docRoot}training/basics/firstapp/index.html">Building +Your First App</a>, you must use intents to navigate between activities in your own app. You +generally do so with an <em>explicit intent</em>, which defines the exact class name of the +component you want to start. However, when you want to have a separate app perform an action, such +as "view a map," you must use an <em>implicit intent</em>.</p> + +<p>This lesson shows you how to create an implicit intent for a particular action, and how to use it +to start an activity that performs the action in another app.</p> + + + +<h2 id="Build">Build an Implicit Intent</h2> + +<p>Implicit intents do not declare the class name of the component to start, but instead declare an +action to perform. The action specifies the thing you want to do, such as <em>view</em>, +<em>edit</em>, <em>send</em>, or <em>get</em> something. Intents often also include data associated +with the action, such as the address you want to view, or the email message you want to send. +Depending on the intent you want to create, the data might be a {@link android.net.Uri}, +one of several other data types, or the intent might not need data at all.</p> + +<p>If your data is a {@link android.net.Uri}, there's a simple {@link +android.content.Intent#Intent(String,Uri) Intent()} constructor you can use define the action and +data.</p> + +<p>For example, here's how to create an intent to initiate a phone call using the {@link +android.net.Uri} data to specify the telephone number:</p> + +<pre> +Uri number = Uri.parse("tel:5551234"); +Intent callIntent = new Intent(Intent.ACTION_DIAL, number); +</pre> + +<p>When your app invokes this intent by calling {@link android.app.Activity#startActivity +startActivity()}, the Phone app initiates a call to the given phone number.</p> + +<p>Here are a couple other intents and their action and {@link android.net.Uri} data +pairs:</p> + +<ul> + <li>View a map: +<pre> +// Map point based on address +Uri location = Uri.parse("geo:0,0?q=1600+Amphitheatre+Parkway,+Mountain+View,+California"); +// Or map point based on latitude/longitude +// Uri location = Uri.parse("geo:37.422219,-122.08364?z=14"); // z param is zoom level +Intent mapIntent = new Intent(Intent.ACTION_VIEW, location); +</pre> + </li> + <li>View a web page: +<pre> +Uri webpage = Uri.parse("http://www.android.com"); +Intent webIntent = new Intent(Intent.ACTION_VIEW, webpage); +</pre> + </li> +</ul> + +<p>Other kinds of implicit intents require "extra" data that provide different data types, +such as a string. You can add one or more pieces of extra data using the various {@link +android.content.Intent#putExtra(String,String) putExtra()} methods.</p> + +<p>By default, the system determines the appropriate MIME type required by an intent based on the +{@link android.net.Uri} data that's included. If you don't include a {@link android.net.Uri} in the +intent, you should usually use {@link android.content.Intent#setType setType()} to specify the type +of data associated with the intent. Setting the MIME type further specifies which kinds of +activities should receive the intent.</p> + +<p>Here are some more intents that add extra data to specify the desired action:</p> + +<ul> + <li>Send an email with an attachment: +<pre> +Intent emailIntent = new Intent(Intent.ACTION_SEND); +// The intent does not have a URI, so declare the "text/plain" MIME type +emailIntent.setType(HTTP.PLAIN_TEXT_TYPE); +emailIntent.putExtra(Intent.EXTRA_EMAIL, new String[] {"jon@example.com"}); // recipients +emailIntent.putExtra(Intent.EXTRA_SUBJECT, "Email subject"); +emailIntent.putExtra(Intent.EXTRA_TEXT, "Email message text"); +emailIntent.putExtra(Intent.EXTRA_STREAM, Uri.parse("content://path/to/email/attachment"); +// You can also attach multiple items by passing an ArrayList of Uris +</pre> + </li> + <li>Create a calendar event: +<pre> +Intent calendarIntent = new Intent(Intent.ACTION_INSERT, Events.CONTENT_URI); +Calendar beginTime = Calendar.getInstance().set(2012, 0, 19, 7, 30); +Calendar endTime = Calendar.getInstance().set(2012, 0, 19, 10, 30); +calendarIntent.putExtra(CalendarContract.EXTRA_EVENT_BEGIN_TIME, beginTime.getTimeInMillis()); +calendarIntent.putExtra(CalendarContract.EXTRA_EVENT_END_TIME, endTime.getTimeInMillis()); +calendarIntent.putExtra(Events.TITLE, "Ninja class"); +calendarIntent.putExtra(Events.EVENT_LOCATION, "Secret dojo"); +</pre> +<p class="note"><strong>Note:</strong> This intent for a calendar event is supported only with API +level 14 and higher.</p> + </li> +</ul> + +<p class="note"><strong>Note:</strong> It's important that you define your {@link +android.content.Intent} to be as specific as possible. For example, if you want to display an image +using the {@link android.content.Intent#ACTION_VIEW} intent, you should specify a MIME type of +{@code image/*}. This prevents apps that can "view" other types of data (like a map app) from being +triggered by the intent.</p> + + + +<h2 id="Verify">Verify There is an App to Receive the Intent</h2> + +<p>Although the Android platform guarantees that certain intents will resolve to one of the +built-in apps (such as the Phone, Email, or Calendar app), you should always include a +verification step before invoking an intent.</p> + +<p class="caution"><strong>Caution:</strong> If you invoke an intent and there is no app +available on the device that can handle the intent, your app will crash.</p> + +<p>To verify there is an activity available that can respond to the intent, call {@link +android.content.pm.PackageManager#queryIntentActivities queryIntentActivities()} to get a list +of activities capable of handling your {@link android.content.Intent}. If the returned {@link +java.util.List} is not empty, you can safely use the intent. For example:</p> + +<pre> +PackageManager packageManager = {@link android.content.Context#getPackageManager()}; +List<ResolveInfo> activities = packageManager.queryIntentActivities(intent, 0); +boolean isIntentSafe = activities.size() > 0; +</pre> + +<p>If <code>isIntentSafe</code> is <code>true</code>, then at least one app will respond to +the intent. If it is <code>false</code>, then there aren't any apps to handle the intent.</p> + +<p class="note"><strong>Note:</strong> You should perform this check when your activity first +starts in case you need to disable the feature that uses the intent before the user attempts to use +it. If you know of a specific app that can handle the intent, you can also provide a link for the +user to download the app (see how to <a +href="{@docRoot}guide/publishing/publishing.html#marketintent">link to an app on Google +Play</a>).</p> + + +<h2 id="StartActivity">Start an Activity with the Intent</h2> + +<div class="figure" style="width:200px"> + <img src="{@docRoot}images/training/basics/intents-choice.png" alt="" /> + <p class="img-caption"><strong>Figure 1.</strong> Example of the selection dialog that appears +when more than one app can handle an intent.</p> +</div> + +<p>Once you have created your {@link android.content.Intent} and set the extra info, call {@link +android.app.Activity#startActivity startActivity()} to send it to the system. If the system +identifies more than one activity that can handle the intent, it displays a dialog for the user to +select which app to use, as shown in figure 1. If there is only one activity that handles the +intent, the system immediately starts it.</p> + +<pre> +startActivity(intent); +</pre> + +<p>Here's a complete example that shows how to create an intent to view a map, verify that an +app exists to handle the intent, then start it:</p> + +<pre> +// Build the intent +Uri location = Uri.parse("geo:0,0?q=1600+Amphitheatre+Parkway,+Mountain+View,+California"); +Intent mapIntent = new Intent(Intent.ACTION_VIEW, location); + +// Verify it resolves +PackageManager packageManager = {@link android.content.Context#getPackageManager()}; +List<ResolveInfo> activities = packageManager.queryIntentActivities(mapIntent, 0); +boolean isIntentSafe = activities.size() > 0; + +// Start an activity if it's safe +if (isIntentSafe) { + startActivity(mapIntent); +} +</pre> + + + + diff --git a/docs/html/training/basics/location/currentlocation.jd b/docs/html/training/basics/location/currentlocation.jd new file mode 100644 index 0000000..4692530 --- /dev/null +++ b/docs/html/training/basics/location/currentlocation.jd @@ -0,0 +1,155 @@ +page.title=Obtaining the Current Location +parent.title=Making Your App Location Aware +parent.link=index.html + +trainingnavtop=true +previous.title=Using the Location Manager +previous.link=locationmanager.html +next.title=Displaying the Location Address +next.link=geocoding.html + + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="currentlocation.html#TaskSetupLocationListener">Set Up the Location Listener</a></li> + <li><a href="currentlocation.html#TaskHandleLocationUpdates">Handle Multiple Sources of Location Updates</a></li> + <li><a href="currentlocation.html#TaskGetLastKnownLocation">Use getLastKnownLocation() Wisely</a></li> + <li><a href="currentlocation.html#TaskTerminateUpdates">Terminate Location Updates</a></li> +</ol> + +<h2>You should also read</h2> + +<ul> + <li><a href="{@docRoot}guide/topics/location/index.html">Location and Maps</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/LocationAware.zip" class="button">Download + the sample app</a> +<p class="filename">LocationAware.zip</p> +</div> + +</div> +</div> + +<p>After setting up your application to work with {@link android.location.LocationManager}, you can begin to obtain location updates.</p> + +<h2 id="TaskSetupLocationListener">Set Up the Location Listener</h2> + +<p>The {@link android.location.LocationManager} class exposes a number of methods for applications to receive location updates. In its simplest form, you register an event listener, identify the location manager from which you'd like to receive location updates, and specify the minimum time and distance intervals at which to receive location updates. The {@link android.location.LocationListener#onLocationChanged(android.location.Location) onLocationChanged()} callback will be invoked with the frequency that correlates with time and distance intervals.</p> + +<p> +In the sample code snippet below, the location listener is set up to receive notifications at least every 10 seconds and if the device moves by more than 10 meters. The other callback methods notify the application any status change coming from the location provider. +</p> + +<pre> +private final LocationListener listener = new LocationListener() { + + @Override + public void onLocationChanged(Location location) { + // A new location update is received. Do something useful with it. In this case, + // we're sending the update to a handler which then updates the UI with the new + // location. + Message.obtain(mHandler, + UPDATE_LATLNG, + location.getLatitude() + ", " + + location.getLongitude()).sendToTarget(); + + ... + } + ... +}; + +mLocationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, + 10000, // 10-second interval. + 10, // 10 meters. + listener); +</pre> + +<h2 id="TaskHandleLocationUpdates">Handle Multiple Sources of Location Updates</h2> + +<p>Generally speaking, a location provider with greater accuracy (GPS) requires a longer fix time than one with lower accuracy (network-based). If you want to display location data as quickly as possible and update it as more accurate data becomes available, a common practice is to register a location listener with both GPS and network providers. In the {@link android.location.LocationListener#onLocationChanged(android.location.Location) onLocationChanged()} callback, you'll receive location updates from multiple location providers that may have different timestamps and varying levels of accuracy. You'll need to incorporate logic to disambiguate the location providers and discard updates that are stale and less accurate. The code snippet below demonstrates a sample implementation of this logic.</p> + +<pre> +private static final int TWO_MINUTES = 1000 * 60 * 2; + +/** Determines whether one Location reading is better than the current Location fix + * @param location The new Location that you want to evaluate + * @param currentBestLocation The current Location fix, to which you want to compare the new one + */ +protected boolean isBetterLocation(Location location, Location currentBestLocation) { + if (currentBestLocation == null) { + // A new location is always better than no location + return true; + } + + // Check whether the new location fix is newer or older + long timeDelta = location.getTime() - currentBestLocation.getTime(); + boolean isSignificantlyNewer = timeDelta > TWO_MINUTES; + boolean isSignificantlyOlder = timeDelta < -TWO_MINUTES; + boolean isNewer = timeDelta > 0; + + // If it's been more than two minutes since the current location, use the new location + // because the user has likely moved + if (isSignificantlyNewer) { + return true; + // If the new location is more than two minutes older, it must be worse + } else if (isSignificantlyOlder) { + return false; + } + + // Check whether the new location fix is more or less accurate + int accuracyDelta = (int) (location.getAccuracy() - currentBestLocation.getAccuracy()); + boolean isLessAccurate = accuracyDelta > 0; + boolean isMoreAccurate = accuracyDelta < 0; + boolean isSignificantlyLessAccurate = accuracyDelta > 200; + + // Check if the old and new location are from the same provider + boolean isFromSameProvider = isSameProvider(location.getProvider(), + currentBestLocation.getProvider()); + + // Determine location quality using a combination of timeliness and accuracy + if (isMoreAccurate) { + return true; + } else if (isNewer && !isLessAccurate) { + return true; + } else if (isNewer && !isSignificantlyLessAccurate && isFromSameProvider) { + return true; + } + return false; +} + +/** Checks whether two providers are the same */ +private boolean isSameProvider(String provider1, String provider2) { + if (provider1 == null) { + return provider2 == null; + } + return provider1.equals(provider2); +} +</pre> + +<h2 id="TaskGetLastKnownLocation">Use getLastKnownLocation() Wisely</h2> + +<p>The setup time for getting a reasonable location fix may not be acceptable for certain applications. You should consider calling the {@link android.location.LocationManager#getLastKnownLocation(java.lang.String) getLastKnownLocation()} method which simply queries Android for the last location update previously received by any location providers. Keep in mind that the returned location may be stale. You should check the timestamp and accuracy of the returned location and decide whether it is useful for your application. If you elect to discard the location update returned from {@link android.location.LocationManager#getLastKnownLocation(java.lang.String) getLastKnownLocation()} and wait for fresh updates from the location provider(s), you should consider displaying an appropriate message before location data is received.</p> + +<h2 id="TaskTerminateUpdates">Terminate Location Updates</h2> + +<p>When you are done with using location data, you should terminate location update to reduce unnecessary consumption of power and network bandwidth. For example, if the user navigates away from an activity where location updates are displayed, you should stop location update by calling {@link android.location.LocationManager#removeUpdates(android.location.LocationListener) removeUpdates()} in {@link android.app.Activity#onStop()}. ({@link android.app.Activity#onStop()} is called when the activity is no longer visible. If you want to learn more about activity lifecycle, read up on the <a href="/training/basic-activity-lifecycle/stopping.html">Starting and Stopping an Activity</a> lesson.</p> + +<pre> +protected void onStop() { + super.onStop(); + mLocationManager.removeUpdates(listener); +} +</pre> + +<p class="note"><strong>Note:</strong> For applications that need to continuously receive and process location updates like a near-real time mapping application, it is best to incorporate the location update logic in a background service and make use of the system notification bar to make the user aware that location data is being used.</p>
\ No newline at end of file diff --git a/docs/html/training/basics/location/geocoding.jd b/docs/html/training/basics/location/geocoding.jd new file mode 100644 index 0000000..6364976 --- /dev/null +++ b/docs/html/training/basics/location/geocoding.jd @@ -0,0 +1,98 @@ +page.title=Displaying the Location Address +parent.title=Making Your App Location Aware +parent.link=index.html + +trainingnavtop=true +previous.title=Obtaining the Current Location +previous.link=currentlocation.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="geocoding.html#TaskReverseGeocoding">Perform Reverse Geocoding</a></li> +</ol> + +<h2>You should also read</h2> + +<ul> + <li><a href="{@docRoot}guide/topics/location/index.html">Location and Maps</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/LocationAware.zip" class="button">Download + the sample app</a> +<p class="filename">LocationAware.zip</p> +</div> + +</div> +</div> + +<p>As shown in previous lessons, location updates are received in the form of latitude and longitude coordinates. While this format is useful for calculating distance or displaying a pushpin on a map, the decimal numbers make no sense to most end users. If you need to display a location to user, it is much more preferable to display the address instead.</p> + +<h2 id="TaskReverseGeocoding">Perform Reverse Geocoding</h2> + +<p>Reverse-geocoding is the process of translating latitude longitude coordinates to a human-readable address. The {@link android.location.Geocoder} API is available for this purpose. Note that behind the scene, the API is dependent on a web service. If such service is unavailable on the device, the API will throw a "Service not Available exception" or return an empty list of addresses. A helper method called {@link android.location.Geocoder#isPresent()} was added in Android 2.3 (API level 9) to check for the existence of the service.</p> + +<p>The following code snippet demonstrates the use of the {@link android.location.Geocoder} API to perform reverse-geocoding. Since the {@link android.location.Geocoder#getFromLocation(double, double, int) getFromLocation()} method is synchronous, you should not invoke it from the UI thread, hence an {@link android.os.AsyncTask} is used in the snippet.</p> + +<pre> +private final LocationListener listener = new LocationListener() { + + public void onLocationChanged(Location location) { + // Bypass reverse-geocoding if the Geocoder service is not available on the + // device. The isPresent() convenient method is only available on Gingerbread or above. + if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.GINGERBREAD && Geocoder.isPresent()) { + // Since the geocoding API is synchronous and may take a while. You don't want to lock + // up the UI thread. Invoking reverse geocoding in an AsyncTask. + (new ReverseGeocodingTask(this)).execute(new Location[] {location}); + } + } + ... +}; + +// AsyncTask encapsulating the reverse-geocoding API. Since the geocoder API is blocked, +// we do not want to invoke it from the UI thread. +private class ReverseGeocodingTask extends AsyncTask<Location, Void, Void> { + Context mContext; + + public ReverseGeocodingTask(Context context) { + super(); + mContext = context; + } + + @Override + protected Void doInBackground(Location... params) { + Geocoder geocoder = new Geocoder(mContext, Locale.getDefault()); + + Location loc = params[0]; + List<Address> addresses = null; + try { + // Call the synchronous getFromLocation() method by passing in the lat/long values. + addresses = geocoder.getFromLocation(loc.getLatitude(), loc.getLongitude(), 1); + } catch (IOException e) { + e.printStackTrace(); + // Update UI field with the exception. + Message.obtain(mHandler, UPDATE_ADDRESS, e.toString()).sendToTarget(); + } + if (addresses != null &s;&s; addresses.size() > 0) { + Address address = addresses.get(0); + // Format the first line of address (if available), city, and country name. + String addressText = String.format("%s, %s, %s", + address.getMaxAddressLineIndex() > 0 ? address.getAddressLine(0) : "", + address.getLocality(), + address.getCountryName()); + // Update the UI via a message handler. + Message.obtain(mHandler, UPDATE_ADDRESS, addressText).sendToTarget(); + } + return null; + } +} +</pre>
\ No newline at end of file diff --git a/docs/html/training/basics/location/index.jd b/docs/html/training/basics/location/index.jd new file mode 100644 index 0000000..48cfbc3 --- /dev/null +++ b/docs/html/training/basics/location/index.jd @@ -0,0 +1,51 @@ +page.title=Making Your App Location Aware + +trainingnavtop=true +startpage=true +next.title=Using the Location Manager +next.link=locationmanager.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>Dependencies and prerequisites</h2> + +<ul> + <li>Android 1.0 or higher (2.3+ for the sample app)</li> +</ul> + +<h2>You should also read</h2> + +<ul> + <li><a href="{@docRoot}guide/topics/location/index.html">Location and Maps</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/LocationAware.zip" class="button">Download + the sample app</a> +<p class="filename">LocationAware.zip</p> +</div> + +</div> +</div> + +<p>Users bring their mobile devices with them almost everywhere. One of the unique features available to mobile applications is location awareness. Knowing the location and using the information wisely can bring a more contextual experience to your users.</p> + +<p>This class teaches you how to incorporate location based services in your Android application. You'll learn a number of methods to receive location updates and related best practices.</p> + +<h2>Lessons</h2> + +<dl> + <dt><b><a href="locationmanager.html">Using the Location Manager</a></b></dt> + <dd>Learn how to set up your application before it can receive location updates in Android.</dd> + + <dt><b><a href="currentlocation.html">Obtaining the Current Location</a></b></dt> + <dd>Learn how to work with underlying location technologies available on the platform to obtain current location.</dd> + + <dt><b><a href="geocoding.html">Displaying a Location Address</a></b></dt> + <dd>Learn how to translate location coordinates into addresses that are readable to users.</dd> +</dl> diff --git a/docs/html/training/basics/location/locationmanager.jd b/docs/html/training/basics/location/locationmanager.jd new file mode 100644 index 0000000..61abcbd --- /dev/null +++ b/docs/html/training/basics/location/locationmanager.jd @@ -0,0 +1,120 @@ +page.title=Using the Location Manager +parent.title=Making Your App Location Aware +parent.link=index.html + +trainingnavtop=true +next.title=Obtaining the Current Location +next.link=currentlocation.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="locationmanager.html#TaskDeclarePermissions">Declare Proper Permissions in Android Manifest</a></li> + <li><a href="locationmanager.html#TaskGetLocationManagerRef">Get a Reference to LocationManager</a></li> + <li><a href="locationmanager.html#TaskPickLocationProvider">Pick a Location Provider</a></li> + <li><a href="locationmanager.html#TaskVerifyProvider">Verify the Location Provider is Enabled</a></li> +</ol> + +<h2>You should also read</h2> + +<ul> + <li><a href="{@docRoot}guide/topics/location/index.html">Location and Maps</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/LocationAware.zip" class="button">Download + the sample app</a> +<p class="filename">LocationAware.zip</p> +</div> + +</div> +</div> + +<p>Before your application can begin receiving location updates, it needs to perform some simple steps to set up access. In this lesson, you'll learn what these steps entail.</p> + +<h2 id="TaskDeclarePermissions">Declare Proper Permissions in Android Manifest</h2> + +<p>The first step of setting up location update access is to declare proper permissions in the manifest. If permissions are missing, the application will get a {@link java.lang.SecurityException} at runtime.</p> + +<p>Depending on the {@link android.location.LocationManager} methods used, either {@link android.Manifest.permission#ACCESS_COARSE_LOCATION} or {@link android.Manifest.permission#ACCESS_FINE_LOCATION} permission is needed. For example, you need to declare the {@link android.Manifest.permission#ACCESS_COARSE_LOCATION} permission if your application uses a network-based location provider only. The more accurate GPS requires the {@link android.Manifest.permission#ACCESS_FINE_LOCATION} permission. +Note that declaring the {@link android.Manifest.permission#ACCESS_FINE_LOCATION} permission implies {@link android.Manifest.permission#ACCESS_COARSE_LOCATION} already.</p> + +<p>Also, if a network-based location provider is used in the application, you'll need to declare the internet permission as well.</p> + +<pre> +<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> +<uses-permission android:name="android.permission.INTERNET" /> +</pre> + +<h2 id="TaskGetLocationManagerRef">Get a Reference to LocationManager</h2> + +<p>{@link android.location.LocationManager} is the main class through which your application can access location services on Android. Similar to other system services, a reference can be obtained from calling the {@link android.content.Context#getSystemService(java.lang.String) getSystemService()} method. If your application intends to receive location updates in the foreground (within an {@link android.app.Activity}), you should usually perform this step in the {@link android.app.Activity#onCreate(android.os.Bundle) onCreate()} method.</p> + +<pre> +LocationManager locationManager = + (LocationManager) this.getSystemService(Context.LOCATION_SERVICE); +</pre> + +<h2 id="TaskPickLocationProvider">Pick a Location Provider</h2> + +<p>While not required, most modern Android-powered devices can receive location updates through multiple underlying technologies, which are abstracted to an application as {@link android.location.LocationProvider} objects. Location providers may have different performance characteristics in terms of time-to-fix, accuracy, monetary cost, power consumption, and so on. Generally, a location provider with a greater accuracy, like the GPS, requires a longer fix time than a less accurate one, such as a network-based location provider.</p> + +<p>Depending on your application's use case, you have to choose a specific location provider, or multiple providers, based on similar tradeoffs. For example, a points of interest check-in application would require higher location accuracy than say, a retail store locator where a city level location fix would suffice. The snippet below asks for a provider backed by the GPS.</p> + +<pre> +LocationProvider provider = + locationManager.getProvider(LocationManager.GPS_PROVIDER); +</pre> + +<p>Alternatively, you can provide some input criteria such as accuracy, power requirement, monetary cost, and so on, and let Android decide a closest match location provider. The snippet below asks for a location provider with fine accuracy and no monetary cost. Note that the criteria may not resolve to any providers, in which case a null will be returned. Your application should be prepared to gracefully handle the situation.</p> + +<pre> +// Retrieve a list of location providers that have fine accuracy, no monetary cost, etc +Criteria criteria = new Criteria(); +criteria.setAccuracy(Criteria.ACCURACY_FINE); +criteria.setCostAllowed(false); +... +String providerName = locManager.getBestProvider(criteria, true); + +// If no suitable provider is found, null is returned. +if (providerName != null) { + ... +} +</pre> + +<h2 id="TaskVerifyProvider">Verify the Location Provider is Enabled</h2> + +<p>Some location providers such as the GPS can be disabled in Settings. It is good practice to check whether the desired location provider is currently enabled by calling the {@link android.location.LocationManager#isProviderEnabled(java.lang.String) isProviderEnabled()} method. If the location provider is disabled, you can offer the user an opportunity to enable it in Settings by firing an {@link android.content.Intent} with the {@link android.provider.Settings#ACTION_LOCATION_SOURCE_SETTINGS} action.</p> + +<pre> +@Override +protected void onStart() { + super.onStart(); + + // This verification should be done during onStart() because the system calls + // this method when the user returns to the activity, which ensures the desired + // location provider is enabled each time the activity resumes from the stopped state. + LocationManager locationManager = + (LocationManager) getSystemService(Context.LOCATION_SERVICE); + final boolean gpsEnabled = locationManager.isProviderEnabled(LocationManager.GPS_PROVIDER); + + if (!gpsEnabled) { + // Build an alert dialog here that requests that the user enable + // the location services, then when the user clicks the "OK" button, + // call enableLocationSettings() + } +} + +private void enableLocationSettings() { + Intent settingsIntent = new Intent(Settings.ACTION_LOCATION_SOURCE_SETTINGS); + startActivity(settingsIntent); +} +</pre> diff --git a/docs/html/training/basics/supporting-devices/index.jd b/docs/html/training/basics/supporting-devices/index.jd new file mode 100644 index 0000000..49ea81d --- /dev/null +++ b/docs/html/training/basics/supporting-devices/index.jd @@ -0,0 +1,49 @@ +page.title=Supporting Different Devices + +trainingnavtop=true +startpage=true +next.title=Supporting Multiple Languages +next.link=languages.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>Dependencies and prerequisites</h2> +<ul> + <li>Android 1.6 or higher</li> +</ul> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/topics/resources/index.html">Application Resources</a></li> + <li><a href="{@docRoot}training/multiscreen/index.html">Designing for Multiple Screens</a></li> +</ul> + + +</div> +</div> + +<p>Android devices come in many shapes and sizes all around the world. With a wide range of device +types, you have an opportunity to reach a huge audience with your app. In order to be as successful +as possible on Android, your app needs to adapt to various device configurations. Some of the +important variations that you should consider include different languages, screen sizes, and +versions of the Android platform.</p> + +<p>This class teaches you how to use basic platform features that leverage alternative +resources and other features so your app can provide an optimized user experience on a +variety of Android-compatible devices, using a single application package (APK).</p> + +<h2>Lessons</h2> + +<dl> + <dt><b><a href="languages.html">Supporting Different Languages</a></b></dt> + <dd>Learn how to support multiple languages with alternative string resources.</dd> + <dt><b><a href="screens.html">Supporting Different Screens</a></b></dt> + <dd>Learn how to optimize the user experience for different screen sizes and densities.</dd> + <dt><b><a href="platforms.html">Supporting Different Platform Versions</a></b></dt> + <dd>Learn how to use APIs available in new versions of Android while continuing to support +older versions of Android.</dd> +</dl> + diff --git a/docs/html/training/basics/supporting-devices/languages.jd b/docs/html/training/basics/supporting-devices/languages.jd new file mode 100644 index 0000000..fcc95c2 --- /dev/null +++ b/docs/html/training/basics/supporting-devices/languages.jd @@ -0,0 +1,134 @@ +page.title=Supporting Different Languages +parent.title=Supporting Different Devices +parent.link=index.html + +trainingnavtop=true +next.title=Supporting Different Screens +next.link=screens.html + +@jd:body + + +<div id="tb-wrapper"> + <div id="tb"> + <h2>This class teaches you to</h2> + <ol> + <li><a href="#CreateDirs">Create Locale Directories and String Files</a></li> + <li><a href="#UseString">Use the String Resources</a></li> + </ol> + <h2>You should also read</h2> + <ul> + <li><a href="{@docRoot}guide/topics/resources/localization.html">Localization</a></li> + </ul> + </div> +</div> + +<p>It’s always a good practice to extract UI strings from your app code and keep them +in an external file. Android makes this easy with a resources directory in each Android +project.</p> + +<p>If you created your project using the Android SDK +Tools (read <a href="{@docRoot}training/basics/firstapp/creating-project.html">Creating an +Android Project</a>), the tools create a <code>res/</code> directory in the top level of +the project. Within this <code>res/</code> directory are subdirectories for various resource +types. There are also a few default files such as <code>res/values/strings.xml</code>, which holds +your string values.</p> + + +<h2 id="CreateDirs">Create Locale Directories and String Files</h2> + +<p>To add support for more languages, create additional <code>values</code> directories inside +<code>res/</code> that include a hyphen and the ISO country code at the end of the +directory name. For example, <code>values-es/</code> is the directory containing simple +resourcess for the Locales with the language code "es". Android loads the appropriate resources +according to the locale settings of the device at run time.</p> + +<p>Once you’ve decided on the languages you will support, create the resource subdirectories and +string resource files. For example:</p> + +<pre class="classic no-pretty-print"> +MyProject/ + res/ + values/ + strings.xml + values-es/ + strings.xml + values-fr/ + strings.xml +</pre> + +<p>Add the string values for each locale into the appropriate file.</p> + +<p>At runtime, the Android system uses the appropriate set of string resources based on the +locale currently set for the user's device.</p> + +<p>For example, the following are some different string resource files for different languages.</p> + + +<p>English (default locale), <code>/values/strings.xml</code>:</p> + +<pre> +<?xml version="1.0" encoding="utf-8"?> +<resources> + <string name="title">My Application</string> + <string name="hello_world">Hello World!</string> +</resources> +</pre> + + +<p>Spanish, <code>/values-es/strings.xml</code>:</p> + +<pre> +<?xml version="1.0" encoding="utf-8"?> +<resources> + <string name="title">Mi Aplicación</string> + <string name="hello_world">Hola Mundo!</string> +</resources> +</pre> + + +<p>French, <code>/values-fr/strings.xml</code>:</p> + +<pre> +<?xml version="1.0" encoding="utf-8"?> +<resources> + <string name="title">Ma Application</string> + <string name="hello_world">Bonjour tout le Monde!</string> +</resources> +</pre> + + +<h2 id="UseString">Use the String Resources</h2> + +<p>You can reference your string resources in your source code and other XML files using the +resource name defined by the {@code <string>} element's {@code name} attribute.</p> + +<p>In your source code, you can refer to a string resource with the syntax {@code +R.string.<string_name>}. There are a variety of methods that accept a string resource this +way.</p> + +<p>For example:</p> + +<pre> +// Get a string resource from your app's {@link android.content.res.Resources} +String hello = {@link android.content.Context#getResources()}.getString(R.string.hello_world); + +// Or supply a string resource to a method that requires a string +TextView textView = new TextView(this); +textView.setText(R.string.hello_world); +</pre> + +<p>In other XML files, you can refer to a string resource with the syntax {@code +@string/<string_name>} whenever the XML attribute accepts a string value.</p> + +<p>For example:</p> + +<pre> +<TextView + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:text="@string/hello_world" /> +</pre> + + + diff --git a/docs/html/training/basics/supporting-devices/platforms.jd b/docs/html/training/basics/supporting-devices/platforms.jd new file mode 100644 index 0000000..0d4e7d9 --- /dev/null +++ b/docs/html/training/basics/supporting-devices/platforms.jd @@ -0,0 +1,138 @@ +page.title=Supporting Different Platform Versions +parent.title=Supporting Different Devices +parent.link=index.html + +trainingnavtop=true +previous.title=Supporting Different Screens +previous.link=screens.html + +@jd:body + + +<div id="tb-wrapper"> + <div id="tb"> + + <h2>This lesson teaches you to</h2> + <ol> + <li><a href="#sdk-versions">Specify Minimum and Target API Levels</a></li> + <li><a href="#version-codes">Check System Version at Runtime</a></li> + <li><a href="#style-themes">Use Platform Styles and Themes</a></li> + </ol> + + <h2>You should also read</h2> + <ul> + <li><a href="{@docRoot}guide/appendix/api-levels.html">Android API Levels</a></li> + <li><a +href="{@docRoot}sdk/compatibility-library.html">Android Support Library</a></li> + </ul> + </div> +</div> + +<p>While the latest versions of Android often provide great APIs for your app, you should continue +to support older versions of Android until more devices get updated. This +lesson shows you how to take advantage of the latest APIs while continuing to support older +versions as well.</p> + +<p>The dashboard for <a +href="http://developer.android.com/resources/dashboard/platform-versions.html">Platform Versions</a> +is updated regularly to show the distribution of active +devices running each version of Android, based on the number of devices that visit the Google Play +Store. Generally, it’s a good practice to support about 90% of the active devices, while +targeting your app to the latest version.</p> + +<p class="note"><strong>Tip:</strong> In order to provide the best features and +functionality across several Android versions, you should use the <a +href="{@docRoot}sdk/compatibility-library.html">Android Support Library</a> in your app, +which allows you to use several recent platform APIs on older versions.</p> + + + +<h2 id="sdk-versions">Specify Minimum and Target API Levels</h2> + +<p>The <a href="{@docRoot}guide/topics/manifest/manifest-intro.html">AndroidManifest.xml</a> file +describes details about your app and +identifies which versions of Android it supports. Specifically, the <code>minSdkVersion</code> +and <code>targetSdkVersion</code> attributes for the <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">{@code <uses-sdk}</a> element +identify the lowest API level with which your app is compatible and the highest API level against +which you’ve designed and tested your app.</p> + +<p>For example:</p> + +<pre> +<manifest xmlns:android="http://schemas.android.com/apk/res/android" ... > + <uses-sdk android:minSdkVersion="4" android:targetSdkVersion="15" /> + ... +</manifest> +</pre> + +<p>As new versions of Android are released, some style and behaviors may change. +To allow your app to take advantage of these changes and ensure that your app fits the style of +each user's device, you should set the +<a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code targetSdkVersion}</a> +value to match the latest Android version +available.</p> + + + +<h2 id="version-codes">Check System Version at Runtime</h2> + +<p>Android provides a unique code for each platform version in the {@link android.os.Build} +constants class. Use these codes within your app to build conditions that ensure the code that +depends on higher API levels is executed only when those APIs are available on the system.</p> + +<pre> +private void setUpActionBar() { + // Make sure we're running on Honeycomb or higher to use ActionBar APIs + if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { + ActionBar actionBar = getActionBar(); + actionBar.setDisplayHomeAsUpEnabled(true); + } +} +</pre> + + + +<p class="note"><strong>Note:</strong> When parsing XML resources, Android ignores XML +attributes that aren’t supported by the current device. So you can safely use XML attributes that +are only supported by newer versions without worrying about older versions breaking when they +encounter that code. For example, if you set the +<code>targetSdkVersion="11"</code>, your app includes the {@link android.app.ActionBar} by default +on Android 3.0 and higher. To then add menu items to the action bar, you need to set +<code>android:showAsAction="ifRoom"</code> in your menu resource XML. It's safe to do this +in a cross-version XML file, because the older versions of Android simply ignore the +<code>showAsAction</code> attribute (that is, you <em>do not</em> need a separate +version in <code>res/menu-v11/</code>).</p> + + + +<h2 id="style-themes">Use Platform Styles and Themes</h2> + +<p>Android provides user experience themes that give apps the look and feel of the +underlying operating system. These themes can be applied to your app within the +manifest file. By using these built in styles and themes, your app will +naturally follow the latest look and feel of Android with each new release.</p> + +<p>To make your activity look like a dialog box:</p> + +<pre><activity android:theme="@android:style/Theme.Dialog"></pre> + +<p>To make your activity have a transparent background:</p> + +<pre><activity android:theme="@android:style/Theme.Translucent"></pre> + +<p>To apply your own custom theme defined in <code>/res/values/styles.xml</code>:</p> + +<pre><activity android:theme="@style/CustomTheme"></pre> + +<p>To apply a theme to your entire app (all activities), add the <code>android:theme</code> +attribute +to the <a href="{@docRoot}guide/topics/manifest/application-element.html">{@code +<application>}</a> element:</p> + +<pre><application android:theme="@style/CustomTheme"></pre> + +<p>For more about creating and using themes, read the <a +href="{@docRoot}guide/topics/ui/themes.html">Styles and Themes</a> guide.</p> + diff --git a/docs/html/training/basics/supporting-devices/screens.jd b/docs/html/training/basics/supporting-devices/screens.jd new file mode 100644 index 0000000..8697cd5 --- /dev/null +++ b/docs/html/training/basics/supporting-devices/screens.jd @@ -0,0 +1,180 @@ +page.title=Supporting Different Screens +parent.title=Supporting Different Devices +parent.link=index.html + +trainingnavtop=true +previous.title=Supporting Different Languages +previous.link=languages.html +next.title=Supporting Different Platform Versions +next.link=platforms.html + +@jd:body + +<div id="tb-wrapper"> + <div id="tb"> + + <h2>This lesson teaches you to</h2> + <ol> + <li><a href="#create-layouts">Create Different Layouts</a></li> + <li><a href="#create-bitmaps">Create Different Bitmaps</a></li> + </ol> + + <h2>You should also read</h2> + <ul> + <li><a href="{@docRoot}training/multiscreen/index.html">Designing for Multiple +Screens</a></li> + <li><a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple +Screens</a></li> + <li><a href="{@docRoot}design/style/iconography.html">Iconography design guide</a></li> + </ul> + </div> +</div> + +<p>Android categorizes device screens using two general properties: size and density. You should +expect that your app will be installed on devices with screens that range in both size +and density. As such, you should include some alternative resources that optimize your app’s +appearance for different screen sizes and densities.</p> + +<ul> + <li>There are four generalized sizes: small, normal, large, xlarge</li> + <li>And four generalized densities: low (ldpi), medium (mdpi), high (hdpi), extra high +(xhdpi)</li> +</ul> + +<p>To declare different layouts and bitmaps you'd like to use for different screens, you must place +these alternative resources in separate directories, similar to how you do for different language +strings.</p> + +<p>Also be aware that the screens orientation (landscape or portrait) is considered a variation of +screen size, so many apps should revise the layout to optimize the user experience in each +orientation.</p> + + +<h2 id="create-layouts">Create Different Layouts</h2> + +<p>To optimize your user experience on different screen sizes, you should create a unique layout XML +file for each screen size you want to support. Each layout should be +saved into the appropriate resources directory, named with a <code>-<screen_size></code> +suffix. For example, a unique layout for large screens should be saved under +<code>res/layout-large/</code>.</p> + +<p class="note"><strong>Note:</strong> Android automatically scales your layout in order to +properly fit the screen. Thus, your layouts for different screen sizes don't +need to worry about the absolute size of UI elements but instead focus on the layout structure that +affects the user experience (such as the size or position of important views relative to sibling +views).</p> + +<p>For example, this project includes a default layout and an alternative layout for <em>large</em> +screens:</p> + +<pre class="classic no-pretty-print"> +MyProject/ + res/ + layout/ + main.xml + layout-large/ + main.xml +</pre> + +<p>The file names must be exactly the same, but their contents are different in order to provide +an optimized UI for the corresponding screen size.</p> + +<p>Simply reference the layout file in your app as usual:</p> + +<pre> +@Override + protected void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + setContentView(R.layout.main); +} +</pre> + +<p>The system loads the layout file from the appropriate layout directory based on screen size of +the device on which your app is running. More information about how Android selects the +appropriate resource is available in the <a +href="{@docRoot}guide/topics/resources/providing-resources.html#BestMatch">Providing Resources</a> +guide.</p> + +<p>As another example, here's a project with an alternative layout for landscape orientation:</p> + +<pre class="classic no-pretty-print"> +MyProject/ + res/ + layout/ + main.xml + layout-land/ + main.xml +</pre> + +<p>By default, the <code>layout/main.xml</code> file is used for portrait orientation.</p> + +<p>If you want a provide a special layout for landscape, including while on large screens, then +you need to use both the <code>large</code> and <code>land</code> qualifier:</p> + +<pre class="classic no-pretty-print"> +MyProject/ + res/ + layout/ # default (portrait) + main.xml + layout-land/ # landscape + main.xml + layout-large/ # large (portrait) + main.xml + layout-large-land/ # large landscape + main.xml +</pre> + +<p class="note"><strong>Note:</strong> Android 3.2 and above supports an advanced method of +defining screen sizes that allows you to specify resources for screen sizes based on +the minimum width and height in terms of density-independent pixels. This lesson does not cover +this new technique. For more information, read <a +href="{@docRoot}training/multiscreen/index.html">Designing for Multiple +Screens</a>.</p> + + + +<h2 id="create-bitmaps">Create Different Bitmaps</h2> + +<p>You should always provide bitmap resources that are properly scaled to each of the generalized +density buckets: low, medium, high and extra-high density. This helps you achieve good graphical +quality and performance on all screen densities.</p> + +<p>To generate these images, you should start with your raw resource in vector format and generate +the images for each density using the following size scale:</p> +<ul> +<li>xhdpi: 2.0</li> +<li>hdpi: 1.5</li> +<li>mdpi: 1.0 (baseline)</li> +<li>ldpi: 0.75</li> +</ul> + +<p>This means that if you generate a 200x200 image for xhdpi devices, you should generate the same +resource in 150x150 for hdpi, 100x100 for mdpi, and 75x75 for ldpi devices.</p> + +<p>Then, place the files in the appropriate drawable resource directory:</p> + +<pre class="classic no-pretty-print"> +MyProject/ + res/ + drawable-xhdpi/ + awesomeimage.png + drawable-hdpi/ + awesomeimage.png + drawable-mdpi/ + awesomeimage.png + drawable-ldpi/ + awesomeimage.png +</pre> + +<p>Any time you reference <code>@drawable/awesomeimage</code>, the system selects the +appropriate bitmap based on the screen's density.</p> + +<p class="note"><strong>Note:</strong> Low-density (ldpi) resources aren’t always necessary. When +you provide hdpi assets, the system scales them down by one half to properly fit ldpi +screens.</p> + +<p>For more tips and guidelines about creating icon assets for your app, see the +<a href="{@docRoot}design/style/iconography.html">Iconography design guide</a>.</p> + + + diff --git a/docs/html/training/camera/cameradirect.jd b/docs/html/training/camera/cameradirect.jd index 03ad119..4b6f0d2 100644 --- a/docs/html/training/camera/cameradirect.jd +++ b/docs/html/training/camera/cameradirect.jd @@ -35,7 +35,7 @@ previous.link=videobasics.html the framework APIs.</p> <p>Directly controlling a device camera requires a lot more code than requesting pictures or videos -from existing camera applications. However, if you want to build a specialized camera application or +from existing camera applications. However, if you want to build a specialized camera application or something fully integrated in your app UI, this lesson shows you how.</p> @@ -95,7 +95,7 @@ camera sensor is picking up.</p> <p>To get started with displaying a preview, you need preview class. The preview requires an implementation of the {@code android.view.SurfaceHolder.Callback} interface, which is used to pass image -data from the camera hardware the application.</p> +data from the camera hardware to the application.</p> <pre> class Preview extends ViewGroup implements SurfaceHolder.Callback { @@ -214,7 +214,7 @@ takePicture()}.</p> <h2 id="TaskRestartPreview">Restart the Preview</h2> -<p>After a picture is taken, you must to restart the preview before the user +<p>After a picture is taken, you must restart the preview before the user can take another picture. In this example, the restart is done by overloading the shutter button.</p> diff --git a/docs/html/training/camera/photobasics.jd b/docs/html/training/camera/photobasics.jd index e6ab43e..3420918 100644 --- a/docs/html/training/camera/photobasics.jd +++ b/docs/html/training/camera/photobasics.jd @@ -55,7 +55,7 @@ for you.</p> <h2 id="TaskManifest">Request Camera Permission</h2> <p>If an essential function of your application is taking pictures, then restrict -its visibility in Android Market to devices that have a camera. To advertise +its visibility on Google Play to devices that have a camera. To advertise that your application depends on having a camera, put a <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"> {@code <uses-feature>}</a> tag in your manifest file:</p> @@ -68,7 +68,7 @@ href="{@docRoot}guide/topics/manifest/uses-feature-element.html"> {@code </pre> <p>If your application uses, but does not require a camera in order to function, add {@code -android:required="false"} to the tag. In doing so, Android Market will allow devices without a +android:required="false"} to the tag. In doing so, Google Play will allow devices without a camera to download your application. It's then your responsibility to check for the availability of the camera at runtime by calling {@link android.content.pm.PackageManager#hasSystemFeature hasSystemFeature(PackageManager.FEATURE_CAMERA)}. diff --git a/docs/html/training/camera/videobasics.jd b/docs/html/training/camera/videobasics.jd index a3512b0..5fe1a3a 100644 --- a/docs/html/training/camera/videobasics.jd +++ b/docs/html/training/camera/videobasics.jd @@ -62,7 +62,7 @@ records video. In this lesson, you make it do this for you.</p> </pre> <p>If your application uses, but does not require a camera in order to function, add {@code -android:required="false"} to the tag. In doing so, Android Market will allow devices without a +android:required="false"} to the tag. In doing so, Google Play will allow devices without a camera to download your application. It's then your responsibility to check for the availability of the camera at runtime by calling {@link android.content.pm.PackageManager#hasSystemFeature hasSystemFeature(PackageManager.FEATURE_CAMERA)}. @@ -107,7 +107,7 @@ public static boolean isIntentAvailable(Context context, String action) { <p>The Android Camera application returns the video in the {@link android.content.Intent} delivered to {@link android.app.Activity#onActivityResult onActivityResult()} as a {@link android.net.Uri} pointing to the video location in storage. The following code -retrieves this image and displays it in a {@link android.widget.VideoView}.</p> +retrieves this video and displays it in a {@link android.widget.VideoView}.</p> <pre> private void handleCameraVideo(Intent intent) { diff --git a/docs/html/training/cloudsync/aesync.jd b/docs/html/training/cloudsync/aesync.jd new file mode 100644 index 0000000..c60d28b --- /dev/null +++ b/docs/html/training/cloudsync/aesync.jd @@ -0,0 +1,432 @@ +page.title=Syncing with App Engine +parent.title=Syncing to the Cloud +parent.link=index.html + +trainingnavtop=true +next.title=Using the Backup API +next.link=backupapi.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<!-- table of contents --> +<h2>This lesson teaches you how to</h2> +<ol> + <li><a href="#prepare">Prepare Your Environment</a></li> + <li><a href="#project">Create Your Project</a></li> + <li><a href="#data">Create the Data Layer</a></li> + <li><a href="#persistence">Create the Persistence Layer</a></li> + <li><a href="#androidapp">Query and Update from the Android App</a></li> + <li><a href="#serverc2dm">Configure the C2DM Server-Side</a></li> + <li><a href="#clientc2dm">Configure the C2DM Client-Side</a></li> +</ol> +<h2>You should also read</h2> + <ul> + <li><a + href="http://developers.google.com/appengine/">App Engine</a></li> + <li><a href="http://code.google.com/android/c2dm/">Android Cloud to Device + Messaging Framework</a></li> + </ul> +<h2>Try it out</h2> + +<p>This lesson uses the Cloud Tasks sample code, originally shown at the +<a href="http://www.youtube.com/watch?v=M7SxNNC429U">Android + AppEngine: A Developer's Dream Combination</a> +talk at Google I/O. You can use the sample application as a source of reusable code for your own +application, or simply as a reference for how the Android and cloud pieces of the overall +application fit together. You can also build the sample application and see how it runs +on your own device or emulator.</p> +<p> + <a href="http://code.google.com/p/cloud-tasks-io/" class="button">Cloud Tasks + App</a> +</p> + +</div> +</div> + +<p>Writing an app that syncs to the cloud can be a challenge. There are many little +details to get right, like server-side auth, client-side auth, a shared data +model, and an API. One way to make this much easier is to use the Google Plugin +for Eclipse, which handles a lot of the plumbing for you when building Android +and App Engine applications that talk to each other. This lesson walks you through building such a project.</p> + +<p>Following this lesson shows you how to:</p> +<ul> + <li>Build Android and Appengine apps that can communicate with each other</li> + <li>Take advantage of Cloud to Device Messaging (C2DM) so your Android app doesn't have to poll for updates</li> +</ul> + +<p>This lesson focuses on local development, and does not cover distribution +(i.e, pushing your App Engine app live, or publishing your Android App to +market), as those topics are covered extensively elsewhere.</p> + +<h2 id="prepare">Prepare Your Environment</h2> +<p>If you want to follow along with the code example in this lesson, you must do +the following to prepare your development environment:</p> +<ul> +<li>Install the <a href="http://code.google.com/eclipse/">Google Plugin for + Eclipse.</a></li> +<li>Install the <a + href="http://code.google.com/webtoolkit/download.html">GWT SDK</a> and the <a + href="http://code.google.com/appengine/">Java App Engine SDK</a>. The <a + href="http://code.google.com/eclipse/docs/getting_started.html">Quick Start + Guide</a> shows you how to install these components.</li> +<li>Sign up for <a href="http://code.google.com/android/c2dm/signup.html">C2DM + access</a>. We strongly recommend <a + href="https://accounts.google.com/SignUp">creating a new Google account</a> specifically for +connecting to C2DM. The server component in this lesson uses this <em>role + account</em> repeatedly to authenticate with Google servers. +</li> +</ul> + +<h2 id="project">Create Your Projects</h2> +<p>After installing the Google Plugin for Eclipse, notice that a new kind of Android project +exists when you create a new Eclipse project: The <strong>App Engine Connected + Android Project</strong> (under the <strong>Google</strong> project category). +A wizard guides you through creating this project, +during the course of which you are prompted to enter the account credentials for the role +account you created.</p> + +<p class="note"><strong>Note:</strong> Remember to enter the credentials for +your <i>role account</i> (the one you created to access C2DM services), not an +account you'd log into as a user, or as an admin.</p> + +<p>Once you're done, you'll see two projects waiting for you in your +workspace—An Android application and an App Engine application. Hooray! +These two applications are already fully functional— the wizard has +created a sample application which lets you authenticate to the App Engine +application from your Android device using AccountManager (no need to type in +your credentials), and an App Engine app that can send messages to any logged-in +device using C2DM. In order to spin up your application and take it for a test +drive, do the following:</p> + +<p>To spin up the Android application, make sure you have an AVD with a platform +version of <em>at least</em> Android 2.2 (API Level 8). Right click on the Android project in +Eclipse, and go to <strong>Debug As > Local App Engine Connected Android + Application</strong>. This launches the emulator in such a way that it can +test C2DM functionality (which typically works through Google Play). It'll +also launch a local instance of App Engine containing your awesome +application.</p> + +<h2 id="data">Create the Data Layer</h2> + +<p>At this point you have a fully functional sample application running. Now +it's time to start changing the code to create your own application.</p> + +<p>First, create the data model that defines the data shared between +the App Engine and Android applications. To start, open up the source folder of +your App Engine project, and navigate down to the <strong>(yourApp)-AppEngine + > src > (yourapp) > server</strong> package. Create a new class in there containing some data you want to +store server-side. The code ends up looking something like this:</p> +<pre> +package com.cloudtasks.server; + +import javax.persistence.*; + +@Entity +public class Task { + + private String emailAddress; + private String name; + private String userId; + private String note; + + @Id + @GeneratedValue(strategy = GenerationType.IDENTITY) + private Long id; + + public Task() { + } + + public String getEmailAddress() { + return this.emailAddress; + } + + public Long getId() { + return this.id; + } + ... +} +</pre> +<p>Note the use of annotations: <code>Entity</code>, <code>Id</code> and +<code>GeneratedValue</code> are all part of the <a + href="http://www.oracle.com/technetwork/articles/javaee/jpa-137156.html">Java + Persistence API</a>. Essentially, the <code>Entity</code> annotation goes +above the class declaration, and indicates that this class represents an entity +in your data layer. The <code>Id</code> and <code>GeneratedValue</code> +annotations, respectively, indicate the field used as a lookup key for this +class, and how that id is generated (in this case, +<code>GenerationType.IDENTITY</code> indicates that the is generated by +the database). You can find more on this topic in the App Engine documentation, +on the page <a + href="http://code.google.com/appengine/docs/java/datastore/jpa/overview.html">Using + JPA with App Engine</a>.</p> + +<p>Once you've written all the classes that represent entities in your data +layer, you need a way for the Android and App Engine applications to communicate +about this data. This communication is enabled by creating a Remote Procedure +Call (RPC) service. +Typically, this involves a lot of monotonous code. Fortunately, there's an easy way! Right +click on the server project in your App Engine source folder, and in the context +menu, navigate to <strong>New > Other</strong> and then, in the resulting +screen, select <strong>Google > RPC Service.</strong> A wizard appears, pre-populated +with all the Entities you created in the previous step, +which it found by seeking out the <code>@Entity</code> annotation in the +source files you added. Pretty neat, right? Click <strong>Finish</strong>, and the wizard +creates a Service class with stub methods for the Create, Retrieve, Update and +Delete (CRUD) operations of all your entities.</p> + +<h2 id="persistence">Create the Persistence Layer</h2> + +<p>The persistence layer is where your application data is stored +long-term, so any information you want to keep for your users needs to go here. +You have several options for writing your persistence layer, depending on +what kind of data you want to store. A few of the options hosted by Google +(though you don't have to use these services) include <a + href="http://code.google.com/apis/storage/">Google Storage for Developers</a> +and App Engine's built-in <a + href="http://code.google.com/appengine/docs/java/gettingstarted/usingdatastore.html">Datastore</a>. +The sample code for this lesson uses DataStore code.</p> + +<p>Create a class in your <code>com.cloudtasks.server</code> package to handle +persistence layer input and output. In order to access the data store, use the <a + href="http://db.apache.org/jdo/api20/apidocs/javax/jdo/PersistenceManager.html">PersistenceManager</a> +class. You can generate an instance of this class using the PMF class in the +<code>com.google.android.c2dm.server.PMF</code> package, and then use that to +perform basic CRUD operations on your data store, like this:</p> +<pre> +/** +* Remove this object from the data store. +*/ +public void delete(Long id) { + PersistenceManager pm = PMF.get().getPersistenceManager(); + try { + Task item = pm.getObjectById(Task.class, id); + pm.deletePersistent(item); + } finally { + pm.close(); + } +} +</pre> + +<p>You can also use <a + href="http://code.google.com/appengine/docs/python/datastore/queryclass.html">Query</a> +objects to retrieve data from your Datastore. Here's an example of a method +that searches out an object by its ID.</p> + +<pre> +public Task find(Long id) { + if (id == null) { + return null; + } + + PersistenceManager pm = PMF.get().getPersistenceManager(); + try { + Query query = pm.newQuery("select from " + Task.class.getName() + + " where id==" + id.toString() + " && emailAddress=='" + getUserEmail() + "'"); + List<Task> list = (List<Task>) query.execute(); + return list.size() == 0 ? null : list.get(0); + } catch (RuntimeException e) { + System.out.println(e); + throw e; + } finally { + pm.close(); + } +} +</pre> + +<p>For a good example of a class that encapsulates the persistence layer for +you, check out the <a + href="http://code.google.com/p/cloud-tasks-io/source/browse/trunk/CloudTasks-AppEngine/src/com/cloudtasks/server/DataStore.java">DataStore</a> +class in the Cloud Tasks app.</p> + + + +<h2 id="androidapp">Query and Update from the Android App</h2> + +<p>In order to keep in sync with the App Engine application, your Android application +needs to know how to do two things: Pull data from the cloud, and send data up +to the cloud. Much of the plumbing for this is generated by the +plugin, but you need to wire it up to your Android user interface yourself.</p> + +<p>Pop open the source code for the main Activity in your project and look for +<code><YourProjectName> Activity.java</code>, then for the method +<code>setHelloWorldScreenContent()</code>. Obviously you're not building a +HelloWorld app, so delete this method entirely and replace it +with something relevant. However, the boilerplate code has some very important +characteristics. For one, the code that communicates with the cloud is wrapped +in an {@link android.os.AsyncTask} and therefore <em>not</em> hitting the +network on the UI thread. Also, it gives an easy template for how to access +the cloud in your own code, using the <a + href="http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html">RequestFactory</a> +class generated that was auto-generated for you by the Eclipse plugin (called +MyRequestFactory in the example below), and various {@code Request} types.</p> + +<p>For instance, if your server-side data model included an object called {@code +Task} when you generated an RPC layer it automatically created a +{@code TaskRequest} class for you, as well as a {@code TaskProxy} representing the individual +task. In code, requesting a list of all these tasks from the server looks +like this:</p> + +<pre> +public void fetchTasks (Long id) { + // Request is wrapped in an AsyncTask to avoid making a network request + // on the UI thread. + new AsyncTask<Long, Void, List<TaskProxy>>() { + @Override + protected List<TaskProxy> doInBackground(Long... arguments) { + final List<TaskProxy> list = new ArrayList<TaskProxy>(); + MyRequestFactory factory = Util.getRequestFactory(mContext, + MyRequestFactory.class); + TaskRequest taskRequest = factory.taskNinjaRequest(); + + if (arguments.length == 0 || arguments[0] == -1) { + factory.taskRequest().queryTasks().fire(new Receiver<List<TaskProxy>>() { + @Override + public void onSuccess(List<TaskProxy> arg0) { + list.addAll(arg0); + } + }); + } else { + newTask = true; + factory.taskRequest().readTask(arguments[0]).fire(new Receiver<TaskProxy>() { + @Override + public void onSuccess(TaskProxy arg0) { + list.add(arg0); + } + }); + } + return list; + } + + @Override + protected void onPostExecute(List<TaskProxy> result) { + TaskNinjaActivity.this.dump(result); + } + + }.execute(id); +} +... + +public void dump (List<TaskProxy> tasks) { + for (TaskProxy task : tasks) { + Log.i("Task output", task.getName() + "\n" + task.getNote()); + } +} +</pre> + +<p>This {@link android.os.AsyncTask} returns a list of +<code>TaskProxy</code> objects, and sends it to the debug {@code dump()} method +upon completion. Note that if the argument list is empty, or the first argument +is a -1, all tasks are retrieved from the server. Otherwise, only the ones with +IDs in the supplied list are returned. All the fields you added to the task +entity when building out the App Engine application are available via get/set +methods in the <code>TaskProxy</code> class.</p> + +<p>In order to create new tasks and send them to the cloud, create a request +object and use it to create a proxy object. Then populate the proxy object and +call its update method. Once again, this should be done in an +<code>AsyncTask</code> to avoid doing networking on the UI thread. The end +result looks something like this.</p> + +<pre> +new AsyncTask<Void, Void, Void>() { + @Override + protected Void doInBackground(Void... arg0) { + MyRequestFactory factory = (MyRequestFactory) + Util.getRequestFactory(TasksActivity.this, + MyRequestFactory.class); + TaskRequest request = factory.taskRequest(); + + // Create your local proxy object, populate it + TaskProxy task = request.create(TaskProxy.class); + task.setName(taskName); + task.setNote(taskDetails); + task.setDueDate(dueDate); + + // To the cloud! + request.updateTask(task).fire(); + return null; + } +}.execute(); +</pre> + +<h2 id="serverc2dm">Configure the C2DM Server-Side</h2> + +<p>In order to set up C2DM messages to be sent to your Android device, go back +into your App Engine codebase, and open up the service class that was created +when you generated your RPC layer. If the name of your project is Foo, +this class is called FooService. Add a line to each of the methods for +adding, deleting, or updating data so that a C2DM message is sent to the +user's device. Here's an example of an update task: +</p> + +<pre> +public static Task updateTask(Task task) { + task.setEmailAddress(DataStore.getUserEmail()); + task = db.update(task); + DataStore.sendC2DMUpdate(TaskChange.UPDATE + TaskChange.SEPARATOR + task.getId()); + return task; +} + +// Helper method. Given a String, send it to the current user's device via C2DM. +public static void sendC2DMUpdate(String message) { + UserService userService = UserServiceFactory.getUserService(); + User user = userService.getCurrentUser(); + ServletContext context = RequestFactoryServlet.getThreadLocalRequest().getSession().getServletContext(); + SendMessage.sendMessage(context, user.getEmail(), message); +} +</pre> + +<p>In the following example, a helper class, {@code TaskChange}, has been created with a few +constants. Creating such a helper class makes managing the communication +between App Engine and Android apps much easier. Just create it in the shared +folder, define a few constants (flags for what kind of message you're sending +and a seperator is typically enough), and you're done. By way of example, +the above code works off of a {@code TaskChange} class defined as this:</p> + +<pre> +public class TaskChange { + public static String UPDATE = "Update"; + public static String DELETE = "Delete"; + public static String SEPARATOR = ":"; +} +</pre> + +<h2 id="clientc2dm">Configure the C2DM Client-Side</h2> + +<p>In order to define the Android applications behavior when a C2DM is recieved, +open up the <code>C2DMReceiver</code> class, and browse to the +<code>onMessage()</code> method. Tweak this method to update based on the content +of the message.</p> +<pre> +//In your C2DMReceiver class + +public void notifyListener(Intent intent) { + if (listener != null) { + Bundle extras = intent.getExtras(); + if (extras != null) { + String message = (String) extras.get("message"); + String[] messages = message.split(Pattern.quote(TaskChange.SEPARATOR)); + listener.onTaskUpdated(messages[0], Long.parseLong(messages[1])); + } + } +} +</pre> + +<pre> +// Elsewhere in your code, wherever it makes sense to perform local updates +public void onTasksUpdated(String messageType, Long id) { + if (messageType.equals(TaskChange.DELETE)) { + // Delete this task from your local data store + ... + } else { + // Call that monstrous Asynctask defined earlier. + fetchTasks(id); + } +} +</pre> +<p> +Once you have C2DM set up to trigger local updates, you're all done. +Congratulations, you have a cloud-connected Android application!</p> diff --git a/docs/html/training/cloudsync/backupapi.jd b/docs/html/training/cloudsync/backupapi.jd new file mode 100644 index 0000000..3055596 --- /dev/null +++ b/docs/html/training/cloudsync/backupapi.jd @@ -0,0 +1,193 @@ +page.title=Using the Backup API +parent.title=Syncing to the Cloud +parent.link=index.html + +trainingnavtop=true +previous.title=Syncing with App Engine +previous.link=aesync.html + +@jd:body + +<div id="tb-wrapper"> + <div id="tb"> + <h2>This lesson teaches you to</h2> + <ol> + <li><a href="#register">Register for the Android Backup Service</a></li> + <li><a href="#manifest">Configure Your Manifest</a></li> + <li><a href="#agent">Write Your Backup Agent</a></li> + <li><a href="#backup">Request a Backup</a></li> + <li><a href="#restore">Restore from a Backup</a></li> + </ol> + <h2>You should also read</h2> + <ul> + <li><a + href="http://developer.android.com/guide/topics/data/backup.html">Data + Backup</a></li> + </ul> + </div> +</div> + +<p>When a user purchases a new device or resets their existing one, they might +expect that when Google Play restores your app back to their device during the +initial setup, the previous data associated with the app restores as well. By +default, that doesn't happen and all the user's accomplishments or settings in +your app are lost.</p> +<p>For situations where the volume of data is relatively light (less than a +megabyte), like the user's preferences, notes, game high scores or other +stats, the Backup API provides a lightweight solution. This lesson walks you +through integrating the Backup API into your application, and restoring data to +new devices using the Backup API.</p> + +<h2 id="register">Register for the Android Backup Service</h2> +<p>This lesson requires the use of the <a + href="http://code.google.com/android/backup/index.html">Android Backup + Service</a>, which requires registration. Go ahead and <a + href="http://code.google.com/android/backup/signup.html">register here</a>. Once +that's done, the service pre-populates an XML tag for insertion in your Android +Manifest, which looks like this:</p> +<pre> +<meta-data android:name="com.google.android.backup.api_key" +android:value="ABcDe1FGHij2KlmN3oPQRs4TUvW5xYZ" /> +</pre> +<p>Note that each backup key works with a specific package name. If you have +different applications, register separate keys for each one.</p> + + +<h2 id="manifest">Configure Your Manifest</h2> +<p>Use of the Android Backup Service requires two additions to your application +manifest. First, declare the name of the class that acts as your backup agent, +then add the snippet above as a child element of the Application tag. Assuming +your backup agent is going to be called {@code TheBackupAgent}, here's an example of +what the manifest looks like with this tag included:</p> + +<pre> +<application android:label="MyApp" + android:backupAgent="TheBackupAgent"> + ... + <meta-data android:name="com.google.android.backup.api_key" + android:value="ABcDe1FGHij2KlmN3oPQRs4TUvW5xYZ" /> + ... +</application> +</pre> +<h2 id="agent">Write Your Backup Agent</h2> +<p>The easiest way to create your backup agent is by extending the wrapper class +{@link android.app.backup.BackupAgentHelper}. Creating this helper class is +actually a very simple process. Just create a class with the same name as you +used in the manifest in the previous step (in this example, {@code +TheBackupAgent}), +and extend {@code BackupAgentHelper}. Then override the {@link +android.app.backup.BackupAgent#onCreate()}.</p> + +<p>Inside the {@link android.app.backup.BackupAgent#onCreate()} method, create a {@link +android.app.backup.BackupHelper}. These helpers are +specialized classes for backing up certain kinds of data. The Android framework +currently includes two such helpers: {@link +android.app.backup.FileBackupHelper} and {@link +android.app.backup.SharedPreferencesBackupHelper}. After you create the helper +and point it at the data you want to back up, just add it to the +BackupAgentHelper using the {@link android.app.backup.BackupAgentHelper#addHelper(String, BackupHelper) addHelper()} +method, adding a key which is used to +retrieve the data later. In most cases the entire +implementation is perhaps 10 lines of code.</p> + +<p>Here's an example that backs up a high scores file.</p> + +<pre> + import android.app.backup.BackupAgentHelper; + import android.app.backup.FileBackupHelper; + + + public class TheBackupAgent extends BackupAgentHelper { + // The name of the SharedPreferences file + static final String HIGH_SCORES_FILENAME = "scores"; + + // A key to uniquely identify the set of backup data + static final String FILES_BACKUP_KEY = "myfiles"; + + // Allocate a helper and add it to the backup agent + @Override + void onCreate() { + FileBackupHelper helper = new FileBackupHelper(this, HIGH_SCORES_FILENAME); + addHelper(FILES_BACKUP_KEY, helper); + } +} +</pre> +<p>For added flexibility, {@link android.app.backup.FileBackupHelper}'s +constructor can take a variable number of filenames. You could just as easily +have backed up both a high scores file and a game progress file just by adding +an extra parameter, like this:</p> +<pre> + @Override + void onCreate() { + FileBackupHelper helper = new FileBackupHelper(this, HIGH_SCORES_FILENAME, PROGRESS_FILENAME); + addHelper(FILES_BACKUP_KEY, helper); + } +</pre> +<p>Backing up preferences is similarly easy. Create a {@link +android.app.backup.SharedPreferencesBackupHelper} the same way you did a {@link +android.app.backup.FileBackupHelper}. In this case, instead of adding filenames +to the constructor, add the names of the shared preference groups being used by +your application. Here's an example of how your backup agent helper might look if +high scores are implemented as preferences instead of a flat file:</p> + +<pre> + import android.app.backup.BackupAgentHelper; + import android.app.backup.SharedPreferencesBackupHelper; + + public class TheBackupAgent extends BackupAgentHelper { + // The names of the SharedPreferences groups that the application maintains. These + // are the same strings that are passed to getSharedPreferences(String, int). + static final String PREFS_DISPLAY = "displayprefs"; + static final String PREFS_SCORES = "highscores"; + + // An arbitrary string used within the BackupAgentHelper implementation to + // identify the SharedPreferencesBackupHelper's data. + static final String MY_PREFS_BACKUP_KEY = "myprefs"; + + // Simply allocate a helper and install it + void onCreate() { + SharedPreferencesBackupHelper helper = + new SharedPreferencesBackupHelper(this, PREFS_DISPLAY, PREFS_SCORES); + addHelper(MY_PREFS_BACKUP_KEY, helper); + } + } +</pre> + +<p>You can add as many backup helper instances to your backup agent helper as you +like, but remember that you only need one of each type. One {@link +android.app.backup.FileBackupHelper} handles all the files that you need to back up, and one +{@link android.app.backup.SharedPreferencesBackupHelper} handles all the shared +preferencegroups you need backed up. +</p> + + +<h2 id="backup">Request a Backup</h2> +<p>In order to request a backup, just create an instance of the {@link +android.app.backup.BackupManager}, and call it's {@link +android.app.backup.BackupManager#dataChanged()} method.</p> + +<pre> + import android.app.backup.BackupManager; + ... + + public void requestBackup() { + BackupManager bm = new BackupManager(this); + bm.dataChanged(); + } +</pre> + +<p>This call notifies the backup manager that there is data ready to be backed +up to the cloud. At some point in the future, the backup manager then calls +your backup agent's {@link +android.app.backup.BackupAgent#onBackup(ParcelFileDescriptor, BackupDataOutput, +ParcelFileDescriptor) onBackup()} method. You can make +the call whenever your data has changed, without having to worry about causing +excessive network activity. If you request a backup twice before a backup +occurs, the backup only occurs once.</p> + + +<h2 id="restore">Restore from a Backup</h2> +<p>Typically you shouldn't ever have to manually request a restore, as it +happens automatically when your application is installed on a device. However, +if it <em>is</em> necessary to trigger a manual restore, just call the +{@link android.app.backup.BackupManager#requestRestore(RestoreObserver) requestRestore()} method.</p> diff --git a/docs/html/training/cloudsync/index.jd b/docs/html/training/cloudsync/index.jd new file mode 100644 index 0000000..e53844b --- /dev/null +++ b/docs/html/training/cloudsync/index.jd @@ -0,0 +1,34 @@ +page.title=Syncing to the Cloud + +trainingnavtop=true +startpage=true +next.title=Syncing with App Engine +next.link=aesync.html + +@jd:body + +<p>By providing powerful APIs for internet connectivity, the Android framework +helps you build rich cloud-enabled apps that sync their data to a remote web +service, making sure all your devices always stay in sync, and your valuable +data is always backed up to the cloud.</p> + +<p>This class covers different strategies for cloud enabled applications. It +covers syncing data with the cloud using your own back-end web application, and +backing up data using the cloud so that users can restore their data when +installing your application on a new device. +</p> + +<h2>Lessons</h2> + +<dl> + <dt><strong><a href="aesync.html">Syncing with App Engine.</a></strong></dt> + <dd>Learn how to create a paired App Engine app and Android app which share a + data model, authenticates using the AccountManager, and communicate with each + other via REST and C2DM.</dd> + <dt><strong><a href="backupapi.html">Using the Backup + API</a></strong></dt> + <dd>Learn how to integrate the Backup API into your Android Application, so + that user data such as preferences, notes, and high scores update seamlessly + across all of a user's devices</dd> +</dl> + diff --git a/docs/html/training/design-navigation/ancestral-temporal.jd b/docs/html/training/design-navigation/ancestral-temporal.jd index 02e43e1..ab6a64d 100644 --- a/docs/html/training/design-navigation/ancestral-temporal.jd +++ b/docs/html/training/design-navigation/ancestral-temporal.jd @@ -21,6 +21,7 @@ next.link=wireframing.html <h2>You should also read</h2> <ul> + <li><a href="{@docRoot}design/patterns/navigation.html">Android Design: Navigation</a></li> <li><a href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">Tasks and Back Stack</a></li> </ul> @@ -28,32 +29,65 @@ next.link=wireframing.html </div> -<p>Now that users can navigate <a href="descendant-lateral.html">deep into</a> the application's screen hierarchy, we need to provide a method for navigating up the hierarchy, to parent and ancestor screens. Additionally, we should ensure that temporal navigation via the BACK button is respected to respect Android conventions.</p> +<p>Now that users can navigate <a href="descendant-lateral.html">deep into</a> the application's +screen hierarchy, we need to provide a method for navigating up the hierarchy, to parent and +ancestor screens. Additionally, we should ensure that temporal navigation via the <em>Back</em> +button is respected to respect Android conventions.</p> +<div class="design-announce"> +<p><strong>Back/Up Navigation Design</strong></p> + <p>For design guidelines, read Android Design's <a + href="{@docRoot}design/patterns/navigation.html">Navigation</a> pattern guide.</p> +</div> <h2 id="temporal-navigation">Support Temporal Navigation: <em>Back</em></h2> -<p>Temporal navigation, or navigation between historical screens, is deeply rooted in the Android system. All Android users expect the BACK button to take them to the previous screen, regardless of other state. The set of historical screens is always rooted at the user's Launcher application (the phone's "home" screen). That is, pressing BACK enough times should land you back at the Launcher, after which the BACK button will do nothing.</p> +<p>Temporal navigation, or navigation between historical screens, is deeply rooted in the Android +system. All Android users expect the <em>Back</em> button to take them to the previous screen, +regardless of other state. The set of historical screens is always rooted at the user's Launcher +application (the phone's "home" screen). That is, pressing <em>Back</em> enough times should land +you back at the Launcher, after which the <em>Back</em> button will do nothing.</p> <img src="{@docRoot}images/training/app-navigation-ancestral-navigate-back.png" - alt="The BACK button behavior after entering the Email app from the People (or Contacts) app" id="figure-navigate-back"> + alt="The Back button behavior after entering the Email app from the People (or Contacts) app" +id="figure-navigate-back"> -<p class="img-caption"><strong>Figure 1.</strong> The BACK button behavior after entering the Email app from the People (or Contacts) app.</p> +<p class="img-caption"><strong>Figure 1.</strong> The <em>Back</em> button behavior after entering +the Email app from the People (or Contacts) app.</p> -<p>Applications generally don't have to worry about managing the BACK button themselves; the system handles <a href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">tasks and the <em>back stack</em></a>, or the list of previous screens, automatically. The BACK button by default simply traverses this list of screens, removing the current screen from the list upon being pressed.</p> +<p>Applications generally don't have to worry about managing the <em>Back</em> button themselves; +the system handles <a href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">tasks and +the <em>back stack</em></a>, or the list of previous screens, automatically. The <em>Back</em> +button by default simply traverses this list of screens, removing the current screen from the list +upon being pressed.</p> -<p>There are, however, cases where you may want to override the behavior for BACK. For example, if your screen contains an embedded web browser where users can interact with page elements to navigate between web pages, you may wish to trigger the embedded browser's default <em>back</em> behavior when users press the device's BACK button. Upon reaching the beginning of the browser's internal history, you should always defer to the system's default behavior for the BACK button.</p> +<p>There are, however, cases where you may want to override the behavior for <em>Back</em>. For +example, if your screen contains an embedded web browser where users can interact with page elements +to navigate between web pages, you may wish to trigger the embedded browser's default <em>back</em> +behavior when users press the device's <em>Back</em> button. Upon reaching the beginning of the +browser's internal history, you should always defer to the system's default behavior for the +<em>Back</em> button.</p> <h2 id="ancestral-navigation">Provide Ancestral Navigation: <em>Up</em> and <em>Home</em></h2> -<p>Before Android 3.0, the most common form of ancestral navigation was the <em>Home</em> metaphor. This was generally implemented as a <em>Home</em> item accessible via the device's MENU button, or a <em>Home</em> button at the top-left of the screen, usually as a component of the <a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a>. Upon selecting <em>Home</em>, the user would be taken to the screen at the top of the screen hierarchy, generally known as the application's home screen.</p> +<p>Before Android 3.0, the most common form of ancestral navigation was the <em>Home</em> metaphor. +This was generally implemented as a <em>Home</em> item accessible via the device's <em>Menu</em> +button, or a <em>Home</em> button at the top-left of the screen, usually as a component of the +Action Bar (<a href="{@docRoot}design/patterns/actionbar.html">pattern docs</a> at Android Design). +Upon selecting <em>Home</em>, the user would be taken to the screen at the top of the screen +hierarchy, generally known as the application's home screen.</p> <p>Providing direct access to the application's home screen can give the user a sense of comfort and security. Regardless of where they are in the application, if they get lost in the app, they can select <em>Home</em> to arrive back at the familiar home screen.</p> -<p>Android 3.0 introduced the <em>Up</em> metaphor, which is presented in the Action Bar as a substitute for the <em>Home</em> button described above. Upon tapping <em>Up</em>, the user should be taken to the parent screen in the hierarchy. This navigation step is usually the previous screen (as described with the BACK button discussion above), but this is not universally the case. Thus, developers must ensure that <em>Up</em> for each screen navigates to a single, predetermined parent screen.</p> +<p>Android 3.0 introduced the <em>Up</em> metaphor, which is presented in the Action Bar as a +substitute for the <em>Home</em> button described above. Upon tapping <em>Up</em>, the user should +be taken to the parent screen in the hierarchy. This navigation step is usually the previous screen +(as described with the <em>Back</em> button discussion above), but this is not universally the case. +Thus, developers must ensure that <em>Up</em> for each screen navigates to a single, predetermined +parent screen.</p> <img src="{@docRoot}images/training/app-navigation-ancestral-navigate-up.png" @@ -64,6 +98,12 @@ next.link=wireframing.html <p>In some cases, it's appropriate for <em>Up</em> to perform an action rather than navigating to a parent screen. Take for example, the Gmail application for Android 3.0-based tablets. When viewing a mail conversation while holding the device in landscape, the conversation list, as well as the conversation details are presented side-by-side. This is a form of parent-child screen grouping, as discussed in a <a href="multiple-sizes.html">previous lesson</a>. However, when viewing a mail conversation in the portrait orientation, only the conversation details are shown. The <em>Up</em> button is used to temporarily show the parent pane, which slides in from the left of the screen. Pressing the <em>Up</em> button again while the left pane is visible exits the context of the individual conversation, up to a full-screen list of conversations.</p> -<p class="note"><strong>Implementation Note:</strong> As a best practice, when implementing either <em>Home</em> or <em>Up</em>, make sure to clear the back stack of any descendent screens. For <em>Home</em>, the only remaining screen on the back stack should be the home screen. For <em>Up</em> navigation, the current screen should be removed from the back stack, unless BACK navigates across screen hierarchies. You can use the {@link android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP} and {@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK} intent flags together to achieve this.</p> +<p class="note"><strong>Implementation Note:</strong> As a best practice, when implementing either +<em>Home</em> or <em>Up</em>, make sure to clear the back stack of any descendent screens. For +<em>Home</em>, the only remaining screen on the back stack should be the home screen. For +<em>Up</em> navigation, the current screen should be removed from the back stack, unless +<em>Back</em> navigates across screen hierarchies. You can use the {@link +android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP} and {@link +android.content.Intent#FLAG_ACTIVITY_NEW_TASK} intent flags together to achieve this.</p> <p>In the last lesson, we apply the concepts discussed in all of the lessons so far to create interaction design wireframes for our example news application.</p> diff --git a/docs/html/training/design-navigation/descendant-lateral.jd b/docs/html/training/design-navigation/descendant-lateral.jd index ebfd913..2d97e40 100644 --- a/docs/html/training/design-navigation/descendant-lateral.jd +++ b/docs/html/training/design-navigation/descendant-lateral.jd @@ -18,9 +18,18 @@ next.link=ancestral-temporal.html <li><a href="#buttons">Buttons and Simple Targets</a></li> <li><a href="#lists">Lists, Grids, Carousels, and Stacks</a></li> <li><a href="#tabs">Tabs</a></li> - <li><a href="#paging">Horizontal Paging</a></li> + <li><a href="#paging">Horizontal Paging (Swipe Views)</a></li> </ol> +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}design/building-blocks/buttons.html">Android Design: Buttons</a></li> + <li><a href="{@docRoot}design/building-blocks/lists.html">Android Design: Lists</a></li> + <li><a href="{@docRoot}design/building-blocks/grid-lists.html">Android Design: Grid Lists</a></li> + <li><a href="{@docRoot}design/building-blocks/tabs.html">Android Design: Tabs</a></li> + <li><a href="{@docRoot}design/patterns/swipe-views.html">Android Design: Swipe Views</a></li> +</ul> + </div> </div> @@ -48,6 +57,12 @@ next.link=ancestral-temporal.html <h2 id="buttons">Buttons and Simple Targets</h2> +<div class="design-announce"> +<p><strong>Button Design</strong></p> + <p>For design guidelines, read Android Design's <a + href="{@docRoot}design/building-blocks/buttons.html">Buttons</a> guide.</p> +</div> + <p>For section-related screens, offering touchable and keyboard-focusable targets in the parent is generally the most straightforward and familiar kind of touch-based navigation interface. Examples of such targets include buttons, fixed-size list views, or text links, although the latter is not an ideal UI (user interface) element for touch-based navigation. Upon selecting one of these targets, the child screen is opened, replacing the current context (screen) entirely. Buttons and other simple targets are rarely used for representing items in a collection.</p> @@ -64,6 +79,13 @@ next.link=ancestral-temporal.html <h2 id="lists">Lists, Grids, Carousels, and Stacks</h2> +<div class="design-announce"> +<p><strong>List and Grid List Design</strong></p> + <p>For design guidelines, read Android Design's <a + href="{@docRoot}design/building-blocks/lists.html">Lists</a> and <a + href="{@docRoot}design/building-blocks/grid-lists.html">Grid Lists</a> guides.</p> +</div> + <p>For collection-related screens, and especially for textual information, vertically scrolling lists are often the most straightforward and familiar kind of interface. For more visual or media-rich content items such as photos or videos, vertically scrolling grids of items, horizontally scrolling lists (sometimes referred to as <em>carousels</em>), or stacks (sometimes referred to as <em>cards</em>) can be used instead. These UI elements are generally best used for presenting item collections or large sets of child screens (for example, a list of stories or a list of 10 or more news topics), rather than a small set of unrelated, sibling child screens.</p> @@ -80,6 +102,12 @@ next.link=ancestral-temporal.html <h2 id="tabs">Tabs</h2> +<div class="design-announce"> +<p><strong>Tab Design</strong></p> + <p>For design guidelines, read Android Design's <a + href="{@docRoot}design/building-blocks/tabs.html">Tabs</a> guide.</p> +</div> + <p>Using tabs is a very popular solution for lateral navigation. This pattern allows grouping of sibling screens, in that the tab content container in the parent screen can embed child screens that otherwise would be entirely separate contexts. Tabs are most appropriate for small sets (4 or fewer) of section-related screens.</p> @@ -89,7 +117,16 @@ next.link=ancestral-temporal.html <p class="img-caption"><strong>Figure 5.</strong> Example phone and tablet tab-based navigation interfaces with relevant screen map excerpt.</p> -<p>Several best practices apply when using tabs. Tabs should be persistent across immediate related screens. Only the designated content region should change when selecting a tab, and tab indicators should remain available at all times. Additionally, tab switches should not be treated as history. For example, if a user switches from a tab <em>A</em> to another tab <em>B</em>, pressing the BACK button (more on that in the <a href="ancestral-temporal.html">next lesson</a>) should not re-select tab <em>A</em>. Tabs are usually laid out horizontally, although other presentations of tab navigation such as using a drop-down list in the <a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a> are sometimes appropriate. Lastly, and most importantly, <em>tabs should always run along the top of the screen</em>, and should not be aligned to the bottom of the screen.</p> +<p>Several best practices apply when using tabs. Tabs should be persistent across immediate related +screens. Only the designated content region should change when selecting a tab, and tab indicators +should remain available at all times. Additionally, tab switches should not be treated as history. +For example, if a user switches from a tab <em>A</em> to another tab <em>B</em>, pressing the +<em>Back</em> button (more on that in the <a href="ancestral-temporal.html">next lesson</a>) should +not re-select tab <em>A</em>. Tabs are usually laid out horizontally, although other presentations +of tab navigation such as using a drop-down list in the Action Bar (<a +href="{@docRoot}design/patterns/actionbar.html">pattern docs</a> at Android Design) are sometimes +appropriate. Lastly, and most importantly, <em>tabs should always run along the top of the +screen</em>, and should not be aligned to the bottom of the screen.</p> <p>There are some obvious immediate benefits of tabs over simpler list- and button-based navigation:</p> @@ -101,9 +138,15 @@ next.link=ancestral-temporal.html <p>A common criticism is that space must be reserved for the tab indicators, detracting from the space available to tab contents. This consequence is usually acceptable, and the tradeoff commonly weighs in favor of using this pattern. You should also feel free to customize tab indicators, showing text and/or icons to make optimal use of vertical space. When adjusting indicator heights however, ensure that tab indicators are large enough for a human finger to touch without error.</p> -<h2 id="paging">Horizontal Paging</h2> +<h2 id="paging">Horizontal Paging (Swipe Views)</h2> + +<div class="design-announce"> +<p><strong>Swipe Views Design</strong></p> + <p>For design guidelines, read Android Design's <a + href="{@docRoot}design/patterns/swipe-views.html">Swipe Views</a> pattern guides.</p> +</div> -<p>Another popular lateral navigation pattern is horizontal paging. This pattern applies best to collection-related sibling screens, such as a list of categories (world, business, technology, and health stories). Like tabs, this pattern also allows grouping screens in that the parent presents the contents of child screens embedded within its own layout.</p> +<p>Another popular lateral navigation pattern is horizontal paging, also referred to as swipe views. This pattern applies best to collection-related sibling screens, such as a list of categories (world, business, technology, and health stories). Like tabs, this pattern also allows grouping screens in that the parent presents the contents of child screens embedded within its own layout.</p> <img src="{@docRoot}images/training/app-navigation-descendant-lateral-paging.png" diff --git a/docs/html/training/design-navigation/index.jd b/docs/html/training/design-navigation/index.jd index e02d52e..af60717 100644 --- a/docs/html/training/design-navigation/index.jd +++ b/docs/html/training/design-navigation/index.jd @@ -14,7 +14,7 @@ next.link=screen-planning.html <p>This class is not specific to any particular version of the Android platform. It is also primarily design-focused and does not require knowledge of the Android SDK. That said, you should have experience using an Android device for a better understanding of the context in which Android applications run.</p> -<p>You should also have basic familiarity with the <a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a>, used across most applications in devices running Android 3.0 and later.</p> +<p>You should also have basic familiarity with the Action Bar (<a href="{@docRoot}design/patterns/actionbar.html">pattern docs</a> at Android Design), used across most applications in devices running Android 3.0 and later.</p> </div> @@ -41,7 +41,9 @@ Relationships</a></strong></dt> <dd>Learn about techniques for allowing users to navigate deep into, as well as across, your content hierarchy. Also learn about pros and cons of, and best practices for, specific navigational UI elements for various situations.</dd> <dt><strong><a href="ancestral-temporal.html">Providing Ancestral and Temporal Navigation</a></strong></dt> - <dd>Learn how to allow users to navigate upwards in the content hierarchy. Also learn about best practices for the BACK button and temporal navigation, or navigation to previous screens that may not be hierarchically related.</dd> + <dd>Learn how to allow users to navigate upwards in the content hierarchy. Also learn about best +practices for the <em>Back</em> button and temporal navigation, or navigation to previous screens +that may not be hierarchically related.</dd> <dt><strong><a href="wireframing.html">Putting it All Together: Wireframing the Example App</a></strong></dt> <dd>Learn how to create screen wireframes (low-fidelity graphic mockups) representing the screens in a news application based on the desired information model. These wireframes utilize navigational elements discussed in previous lessons to demonstrate intuitive and efficient navigation.</dd> diff --git a/docs/html/training/design-navigation/multiple-sizes.jd b/docs/html/training/design-navigation/multiple-sizes.jd index 7a8139f..ebaec0f 100644 --- a/docs/html/training/design-navigation/multiple-sizes.jd +++ b/docs/html/training/design-navigation/multiple-sizes.jd @@ -22,6 +22,7 @@ next.link=descendant-lateral.html <h2>You should also read</h2> <ul> + <li><a href="{@docRoot}design/patterns/multi-pane-layouts.html">Android Design: Multi-pane Layouts</a></li> <li><a href="{@docRoot}training/multiscreen/index.html">Designing for Multiple Screens</a></li> </ul> @@ -35,6 +36,12 @@ next.link=descendant-lateral.html <h2 id="multi-pane-layouts">Group Screens with Multi-pane Layouts</h2> +<div class="design-announce"> +<p><strong>Multi-pane Layout Design</strong></p> + <p>For design guidelines, read Android Design's <a + href="{@docRoot}design/patterns/multi-pane-layouts.html">Multi-pane Layouts</a> pattern guide.</p> +</div> + <p>3 to 4-inch screens are generally only suitable for showing a single vertical pane of content at a time, be it a list of items, or detail information about an item, etc. Thus on such devices, screens generally map one-to-one with levels in the information hierarchy (<em>categories</em> → <em>object list</em> → <em>object detail</em>).</p> <p>Larger screens such as those found on tablets and TVs, on the other hand, generally have much more available screen space and are able to present multiple panes of content. In landscape, panes are usually ordered from left to right in increasing detail order. Users are especially accustomed to multiple panes on larger screens from years and years of desktop application and desktop web site use. Many desktop applications and websites offer a left-hand navigation pane or use a master/detail two-pane layout.</p> @@ -76,12 +83,12 @@ next.link=descendant-lateral.html <li><strong>Expand/collapse</strong> <img src="{@docRoot}images/training/app-navigation-multiple-sizes-strategy-collapse.png" alt="Expand/collapse strategy"> - <p>A variation on the stretch strategy is to collapse the contents of the left pane when in portrait. This works quite well with master/detail panes where the left (master) pane contains easily collapsible list items. An example would be for a realtime chat application. In landscape, the left list could contain chat contact photos, names, and online statuses. In portrait, horizontal space could be collapsed by hiding contact names and only showing photos and online status indicator icons.</p></li> + <p>A variation on the stretch strategy is to collapse the contents of the left pane when in portrait. This works quite well with master/detail panes where the left (master) pane contains easily collapsible list items. An example would be for a realtime chat application. In landscape, the left list could contain chat contact photos, names, and online statuses. In portrait, horizontal space could be collapsed by hiding contact names and only showing photos and online status indicator icons. Optionally also provide an expand control that allows the user to expand the left pane content to its larger width and vice versa.</p></li> <li><strong>Show/Hide</strong> <img src="{@docRoot}images/training/app-navigation-multiple-sizes-strategy-show-hide.png" alt="Show/Hide strategy"> - <p>In this scenario, the left pane is completely hidden in portrait mode. However, <em>to ensure the functional parity</em> of your screen in portrait and landscape, the left pane should be made available via an onscreen affordance (such as a button). It's usually appropriate to use the <em>Up</em> button in the <a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a> to show the left pane, as is discussed in a <a href="ancestral-temporal.html">later lesson</a>.</p></li> + <p>In this scenario, the left pane is completely hidden in portrait mode. However, <em>to ensure the functional parity</em> of your screen in portrait and landscape, the left pane should be made available via an onscreen affordance (such as a button). It's usually appropriate to use the <em>Up</em> button in the Action Bar (<a href="{@docRoot}design/patterns/actionbar.html">pattern docs</a> at Android Design) to show the left pane, as is discussed in a <a href="ancestral-temporal.html">later lesson</a>.</p></li> <li><strong>Stack</strong> <img src="{@docRoot}images/training/app-navigation-multiple-sizes-strategy-stack.png" diff --git a/docs/html/training/design-navigation/wireframing.jd b/docs/html/training/design-navigation/wireframing.jd index c7687dd..6deceb1 100644 --- a/docs/html/training/design-navigation/wireframing.jd +++ b/docs/html/training/design-navigation/wireframing.jd @@ -121,5 +121,5 @@ previous.link=ancestral-temporal.html <li><a href="{@docRoot}guide/topics/ui/index.html">Developer's Guide: User Interface</a>: learn how to implement your user interface designs using the Android SDK.</li> <li><a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a>: implement tabs, up navigation, on-screen actions, etc. <li><a href="{@docRoot}guide/topics/fundamentals/fragments.html">Fragments</a>: implement re-usable, multi-pane layouts - <li><a href="{@docRoot}sdk/compatibility-library.html">Support Library</a>: implement horizontal paging using <code>ViewPager</code></li> + <li><a href="{@docRoot}sdk/compatibility-library.html">Support Library</a>: implement horizontal paging (swipe views) using <code>ViewPager</code></li> </ul> diff --git a/docs/html/training/displaying-bitmaps/cache-bitmap.jd b/docs/html/training/displaying-bitmaps/cache-bitmap.jd new file mode 100644 index 0000000..94abe21 --- /dev/null +++ b/docs/html/training/displaying-bitmaps/cache-bitmap.jd @@ -0,0 +1,337 @@ +page.title=Caching Bitmaps +parent.title=Displaying Bitmaps Efficiently +parent.link=index.html + +trainingnavtop=true +next.title=Displaying Bitmaps in Your UI +next.link=display-bitmap.html +previous.title=Processing Bitmaps Off the UI Thread +previous.link=process-bitmap.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#memory-cache">Use a Memory Cache</a></li> + <li><a href="#disk-cache">Use a Disk Cache</a></li> + <li><a href="#config-changes">Handle Configuration Changes</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/topics/resources/runtime-changes.html">Handling Runtime Changes</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> + <a href="{@docRoot}shareables/training/BitmapFun.zip" class="button">Download the sample</a> + <p class="filename">BitmapFun.zip</p> +</div> + +</div> +</div> + +<p>Loading a single bitmap into your user interface (UI) is straightforward, however things get more +complicated if you need to load a larger set of images at once. In many cases (such as with +components like {@link android.widget.ListView}, {@link android.widget.GridView} or {@link +android.support.v4.view.ViewPager }), the total number of images on-screen combined with images that +might soon scroll onto the screen are essentially unlimited.</p> + +<p>Memory usage is kept down with components like this by recycling the child views as they move +off-screen. The garbage collector also frees up your loaded bitmaps, assuming you don't keep any +long lived references. This is all good and well, but in order to keep a fluid and fast-loading UI +you want to avoid continually processing these images each time they come back on-screen. A memory +and disk cache can often help here, allowing components to quickly reload processed images.</p> + +<p>This lesson walks you through using a memory and disk bitmap cache to improve the responsiveness +and fluidity of your UI when loading multiple bitmaps.</p> + +<h2 id="memory-cache">Use a Memory Cache</h2> + +<p>A memory cache offers fast access to bitmaps at the cost of taking up valuable application +memory. The {@link android.util.LruCache} class (also available in the <a +href="{@docRoot}reference/android/support/v4/util/LruCache.html">Support Library</a> for use back +to API Level 4) is particularly well suited to the task of caching bitmaps, keeping recently +referenced objects in a strong referenced {@link java.util.LinkedHashMap} and evicting the least +recently used member before the cache exceeds its designated size.</p> + +<p class="note"><strong>Note:</strong> In the past, a popular memory cache implementation was a +{@link java.lang.ref.SoftReference} or {@link java.lang.ref.WeakReference} bitmap cache, however +this is not recommended. Starting from Android 2.3 (API Level 9) the garbage collector is more +aggressive with collecting soft/weak references which makes them fairly ineffective. In addition, +prior to Android 3.0 (API Level 11), the backing data of a bitmap was stored in native memory which +is not released in a predictable manner, potentially causing an application to briefly exceed its +memory limits and crash.</p> + +<p>In order to choose a suitable size for a {@link android.util.LruCache}, a number of factors +should be taken into consideration, for example:</p> + +<ul> + <li>How memory intensive is the rest of your activity and/or application?</li> + <li>How many images will be on-screen at once? How many need to be available ready to come + on-screen?</li> + <li>What is the screen size and density of the device? An extra high density screen (xhdpi) device + like <a href="http://www.android.com/devices/detail/galaxy-nexus">Galaxy Nexus</a> will need a + larger cache to hold the same number of images in memory compared to a device like <a + href="http://www.android.com/devices/detail/nexus-s">Nexus S</a> (hdpi).</li> + <li>What dimensions and configuration are the bitmaps and therefore how much memory will each take + up?</li> + <li>How frequently will the images be accessed? Will some be accessed more frequently than others? + If so, perhaps you may want to keep certain items always in memory or even have multiple {@link + android.util.LruCache} objects for different groups of bitmaps.</li> + <li>Can you balance quality against quantity? Sometimes it can be more useful to store a larger + number of lower quality bitmaps, potentially loading a higher quality version in another + background task.</li> +</ul> + +<p>There is no specific size or formula that suits all applications, it's up to you to analyze your +usage and come up with a suitable solution. A cache that is too small causes additional overhead with +no benefit, a cache that is too large can once again cause {@code java.lang.OutOfMemory} exceptions +and leave the rest of your app little memory to work with.</p> + +<p>Here’s an example of setting up a {@link android.util.LruCache} for bitmaps:</p> + +<pre> +private LruCache<String, Bitmap> mMemoryCache; + +@Override +protected void onCreate(Bundle savedInstanceState) { + ... + // Get memory class of this device, exceeding this amount will throw an + // OutOfMemory exception. + final int memClass = ((ActivityManager) context.getSystemService( + Context.ACTIVITY_SERVICE)).getMemoryClass(); + + // Use 1/8th of the available memory for this memory cache. + final int cacheSize = 1024 * 1024 * memClass / 8; + + mMemoryCache = new LruCache<String, Bitmap>(cacheSize) { + @Override + protected int sizeOf(String key, Bitmap bitmap) { + // The cache size will be measured in bytes rather than number of items. + return bitmap.getByteCount(); + } + }; + ... +} + +public void addBitmapToMemoryCache(String key, Bitmap bitmap) { + if (getBitmapFromMemCache(key) == null) { + mMemoryCache.put(key, bitmap); + } +} + +public Bitmap getBitmapFromMemCache(String key) { + return mMemoryCache.get(key); +} +</pre> + +<p class="note"><strong>Note:</strong> In this example, one eighth of the application memory is +allocated for our cache. On a normal/hdpi device this is a minimum of around 4MB (32/8). A full +screen {@link android.widget.GridView} filled with images on a device with 800x480 resolution would +use around 1.5MB (800*480*4 bytes), so this would cache a minimum of around 2.5 pages of images in +memory.</p> + +<p>When loading a bitmap into an {@link android.widget.ImageView}, the {@link android.util.LruCache} +is checked first. If an entry is found, it is used immediately to update the {@link +android.widget.ImageView}, otherwise a background thread is spawned to process the image:</p> + +<pre> +public void loadBitmap(int resId, ImageView imageView) { + final String imageKey = String.valueOf(resId); + + final Bitmap bitmap = getBitmapFromMemCache(imageKey); + if (bitmap != null) { + mImageView.setImageBitmap(bitmap); + } else { + mImageView.setImageResource(R.drawable.image_placeholder); + BitmapWorkerTask task = new BitmapWorkerTask(mImageView); + task.execute(resId); + } +} +</pre> + +<p>The <a href="process-bitmap.html#BitmapWorkerTask">{@code BitmapWorkerTask}</a> also needs to be +updated to add entries to the memory cache:</p> + +<pre> +class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> { + ... + // Decode image in background. + @Override + protected Bitmap doInBackground(Integer... params) { + final Bitmap bitmap = decodeSampledBitmapFromResource( + getResources(), params[0], 100, 100)); + addBitmapToMemoryCache(String.valueOf(params[0]), bitmap); + return bitmap; + } + ... +} +</pre> + +<h2 id="disk-cache">Use a Disk Cache</h2> + +<p>A memory cache is useful in speeding up access to recently viewed bitmaps, however you cannot +rely on images being available in this cache. Components like {@link android.widget.GridView} with +larger datasets can easily fill up a memory cache. Your application could be interrupted by another +task like a phone call, and while in the background it might be killed and the memory cache +destroyed. Once the user resumes, your application it has to process each image again.</p> + +<p>A disk cache can be used in these cases to persist processed bitmaps and help decrease loading +times where images are no longer available in a memory cache. Of course, fetching images from disk +is slower than loading from memory and should be done in a background thread, as disk read times can +be unpredictable.</p> + +<p class="note"><strong>Note:</strong> A {@link android.content.ContentProvider} might be a more +appropriate place to store cached images if they are accessed more frequently, for example in an +image gallery application.</p> + +<p>Included in the sample code of this class is a basic {@code DiskLruCache} implementation. +However, a more robust and recommended {@code DiskLruCache} solution is included in the Android 4.0 +source code ({@code libcore/luni/src/main/java/libcore/io/DiskLruCache.java}). Back-porting this +class for use on previous Android releases should be fairly straightforward (a <a +href="http://www.google.com/search?q=disklrucache">quick search</a> shows others who have already +implemented this solution).</p> + +<p>Here’s updated example code that uses the simple {@code DiskLruCache} included in the sample +application of this class:</p> + +<pre> +private DiskLruCache mDiskCache; +private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MB +private static final String DISK_CACHE_SUBDIR = "thumbnails"; + +@Override +protected void onCreate(Bundle savedInstanceState) { + ... + // Initialize memory cache + ... + File cacheDir = getCacheDir(this, DISK_CACHE_SUBDIR); + mDiskCache = DiskLruCache.openCache(this, cacheDir, DISK_CACHE_SIZE); + ... +} + +class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> { + ... + // Decode image in background. + @Override + protected Bitmap doInBackground(Integer... params) { + final String imageKey = String.valueOf(params[0]); + + // Check disk cache in background thread + Bitmap bitmap = getBitmapFromDiskCache(imageKey); + + if (bitmap == null) { // Not found in disk cache + // Process as normal + final Bitmap bitmap = decodeSampledBitmapFromResource( + getResources(), params[0], 100, 100)); + } + + // Add final bitmap to caches + addBitmapToCache(String.valueOf(imageKey, bitmap); + + return bitmap; + } + ... +} + +public void addBitmapToCache(String key, Bitmap bitmap) { + // Add to memory cache as before + if (getBitmapFromMemCache(key) == null) { + mMemoryCache.put(key, bitmap); + } + + // Also add to disk cache + if (!mDiskCache.containsKey(key)) { + mDiskCache.put(key, bitmap); + } +} + +public Bitmap getBitmapFromDiskCache(String key) { + return mDiskCache.get(key); +} + +// Creates a unique subdirectory of the designated app cache directory. Tries to use external +// but if not mounted, falls back on internal storage. +public static File getCacheDir(Context context, String uniqueName) { + // Check if media is mounted or storage is built-in, if so, try and use external cache dir + // otherwise use internal cache dir + final String cachePath = Environment.getExternalStorageState() == Environment.MEDIA_MOUNTED + || !Environment.isExternalStorageRemovable() ? + context.getExternalCacheDir().getPath() : context.getCacheDir().getPath(); + + return new File(cachePath + File.separator + uniqueName); +} +</pre> + +<p>While the memory cache is checked in the UI thread, the disk cache is checked in the background +thread. Disk operations should never take place on the UI thread. When image processing is +complete, the final bitmap is added to both the memory and disk cache for future use.</p> + +<h2 id="config-changes">Handle Configuration Changes</h2> + +<p>Runtime configuration changes, such as a screen orientation change, cause Android to destroy and +restart the running activity with the new configuration (For more information about this behavior, +see <a href="{@docRoot}guide/topics/resources/runtime-changes.html">Handling Runtime Changes</a>). +You want to avoid having to process all your images again so the user has a smooth and fast +experience when a configuration change occurs.</p> + +<p>Luckily, you have a nice memory cache of bitmaps that you built in the <a +href="#memory-cache">Use a Memory Cache</a> section. This cache can be passed through to the new +activity instance using a {@link android.app.Fragment} which is preserved by calling {@link +android.app.Fragment#setRetainInstance setRetainInstance(true)}). After the activity has been +recreated, this retained {@link android.app.Fragment} is reattached and you gain access to the +existing cache object, allowing images to be quickly fetched and re-populated into the {@link +android.widget.ImageView} objects.</p> + +<p>Here’s an example of retaining a {@link android.util.LruCache} object across configuration +changes using a {@link android.app.Fragment}:</p> + +<pre> +private LruCache<String, Bitmap> mMemoryCache; + +@Override +protected void onCreate(Bundle savedInstanceState) { + ... + RetainFragment mRetainFragment = + RetainFragment.findOrCreateRetainFragment(getFragmentManager()); + mMemoryCache = RetainFragment.mRetainedCache; + if (mMemoryCache == null) { + mMemoryCache = new LruCache<String, Bitmap>(cacheSize) { + ... // Initialize cache here as usual + } + mRetainFragment.mRetainedCache = mMemoryCache; + } + ... +} + +class RetainFragment extends Fragment { + private static final String TAG = "RetainFragment"; + public LruCache<String, Bitmap> mRetainedCache; + + public RetainFragment() {} + + public static RetainFragment findOrCreateRetainFragment(FragmentManager fm) { + RetainFragment fragment = (RetainFragment) fm.findFragmentByTag(TAG); + if (fragment == null) { + fragment = new RetainFragment(); + } + return fragment; + } + + @Override + public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + <strong>setRetainInstance(true);</strong> + } +} +</pre> + +<p>To test this out, try rotating a device both with and without retaining the {@link +android.app.Fragment}. You should notice little to no lag as the images populate the activity almost +instantly from memory when you retain the cache. Any images not found in the memory cache are +hopefully available in the disk cache, if not, they are processed as usual.</p> diff --git a/docs/html/training/displaying-bitmaps/display-bitmap.jd b/docs/html/training/displaying-bitmaps/display-bitmap.jd new file mode 100644 index 0000000..7a93313 --- /dev/null +++ b/docs/html/training/displaying-bitmaps/display-bitmap.jd @@ -0,0 +1,400 @@ +page.title=Displaying Bitmaps in Your UI +parent.title=Displaying Bitmaps Efficiently +parent.link=index.html + +trainingnavtop=true +previous.title=Caching Bitmaps +previous.link=cache-bitmap.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#viewpager">Load Bitmaps into a ViewPager Implementation</a></li> + <li><a href="#gridview">Load Bitmaps into a GridView Implementation</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}design/patterns/swipe-views.html">Android Design: Swipe Views</a></li> + <li><a href="{@docRoot}design/building-blocks/grid-lists.html">Android Design: Grid Lists</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> + <a href="{@docRoot}shareables/training/BitmapFun.zip" class="button">Download the sample</a> + <p class="filename">BitmapFun.zip</p> +</div> + +</div> +</div> + +<p></p> + +<p>This lesson brings together everything from previous lessons, showing you how to load multiple +bitmaps into {@link android.support.v4.view.ViewPager} and {@link android.widget.GridView} +components using a background thread and bitmap cache, while dealing with concurrency and +configuration changes.</p> + +<h2 id="viewpager">Load Bitmaps into a ViewPager Implementation</h2> + +<p>The <a href="{@docRoot}design/patterns/swipe-views.html">swipe view pattern</a> is an excellent +way to navigate the detail view of an image gallery. You can implement this pattern using a {@link +android.support.v4.view.ViewPager} component backed by a {@link +android.support.v4.view.PagerAdapter}. However, a more suitable backing adapter is the subclass +{@link android.support.v4.app.FragmentStatePagerAdapter} which automatically destroys and saves +state of the {@link android.app.Fragment Fragments} in the {@link android.support.v4.view.ViewPager} +as they disappear off-screen, keeping memory usage down.</p> + +<p class="note"><strong>Note:</strong> If you have a smaller number of images and are confident they +all fit within the application memory limit, then using a regular {@link +android.support.v4.view.PagerAdapter} or {@link android.support.v4.app.FragmentPagerAdapter} might +be more appropriate.</p> + +<p>Here’s an implementation of a {@link android.support.v4.view.ViewPager} with {@link +android.widget.ImageView} children. The main activity holds the {@link +android.support.v4.view.ViewPager} and the adapter:</p> + +<pre> +public class ImageDetailActivity extends FragmentActivity { + public static final String EXTRA_IMAGE = "extra_image"; + + private ImagePagerAdapter mAdapter; + private ViewPager mPager; + + // A static dataset to back the ViewPager adapter + public final static Integer[] imageResIds = new Integer[] { + R.drawable.sample_image_1, R.drawable.sample_image_2, R.drawable.sample_image_3, + R.drawable.sample_image_4, R.drawable.sample_image_5, R.drawable.sample_image_6, + R.drawable.sample_image_7, R.drawable.sample_image_8, R.drawable.sample_image_9}; + + @Override + public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + setContentView(R.layout.image_detail_pager); // Contains just a ViewPager + + mAdapter = new ImagePagerAdapter(getSupportFragmentManager(), imageResIds.length); + mPager = (ViewPager) findViewById(R.id.pager); + mPager.setAdapter(mAdapter); + } + + public static class ImagePagerAdapter extends FragmentStatePagerAdapter { + private final int mSize; + + public ImagePagerAdapter(FragmentManager fm, int size) { + super(fm); + mSize = size; + } + + @Override + public int getCount() { + return mSize; + } + + @Override + public Fragment getItem(int position) { + return ImageDetailFragment.newInstance(position); + } + } +} +</pre> + +<p>The details {@link android.app.Fragment} holds the {@link android.widget.ImageView} children:</p> + +<pre> +public class ImageDetailFragment extends Fragment { + private static final String IMAGE_DATA_EXTRA = "resId"; + private int mImageNum; + private ImageView mImageView; + + static ImageDetailFragment newInstance(int imageNum) { + final ImageDetailFragment f = new ImageDetailFragment(); + final Bundle args = new Bundle(); + args.putInt(IMAGE_DATA_EXTRA, imageNum); + f.setArguments(args); + return f; + } + + // Empty constructor, required as per Fragment docs + public ImageDetailFragment() {} + + @Override + public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + mImageNum = getArguments() != null ? getArguments().getInt(IMAGE_DATA_EXTRA) : -1; + } + + @Override + public View onCreateView(LayoutInflater inflater, ViewGroup container, + Bundle savedInstanceState) { + // image_detail_fragment.xml contains just an ImageView + final View v = inflater.inflate(R.layout.image_detail_fragment, container, false); + mImageView = (ImageView) v.findViewById(R.id.imageView); + return v; + } + + @Override + public void onActivityCreated(Bundle savedInstanceState) { + super.onActivityCreated(savedInstanceState); + final int resId = ImageDetailActivity.imageResIds[mImageNum]; + <strong>mImageView.setImageResource(resId);</strong> // Load image into ImageView + } +} +</pre> + +<p>Hopefully you noticed the issue with this implementation; The images are being read from +resources on the UI thread which can lead to an application hanging and being force closed. Using an +{@link android.os.AsyncTask} as described in the <a href="process-bitmap.html">Processing Bitmaps Off +the UI Thread</a> lesson, it’s straightforward to move image loading and processing to a background +thread:</p> + +<pre> +public class ImageDetailActivity extends FragmentActivity { + ... + + public void loadBitmap(int resId, ImageView imageView) { + mImageView.setImageResource(R.drawable.image_placeholder); + BitmapWorkerTask task = new BitmapWorkerTask(mImageView); + task.execute(resId); + } + + ... // include <a href="process-bitmap.html#BitmapWorkerTask">{@code BitmapWorkerTask}</a> class +} + +public class ImageDetailFragment extends Fragment { + ... + + @Override + public void onActivityCreated(Bundle savedInstanceState) { + super.onActivityCreated(savedInstanceState); + if (ImageDetailActivity.class.isInstance(getActivity())) { + final int resId = ImageDetailActivity.imageResIds[mImageNum]; + // Call out to ImageDetailActivity to load the bitmap in a background thread + ((ImageDetailActivity) getActivity()).loadBitmap(resId, mImageView); + } + } +} +</pre> + +<p>Any additional processing (such as resizing or fetching images from the network) can take place +in the <a href="process-bitmap.html#BitmapWorkerTask">{@code BitmapWorkerTask}</a> without affecting +responsiveness of the main UI. If the background thread is doing more than just loading an image +directly from disk, it can also be beneficial to add a memory and/or disk cache as described in the +lesson <a href="cache-bitmap.html#memory-cache">Caching Bitmaps</a>. Here's the additional +modifications for a memory cache:</p> + +<pre> +public class ImageDetailActivity extends FragmentActivity { + ... + private LruCache<String, Bitmap> mMemoryCache; + + @Override + public void onCreate(Bundle savedInstanceState) { + ... + // initialize LruCache as per <a href="cache-bitmap.html#memory-cache">Use a Memory Cache</a> section + } + + public void loadBitmap(int resId, ImageView imageView) { + final String imageKey = String.valueOf(resId); + + final Bitmap bitmap = mMemoryCache.get(imageKey); + if (bitmap != null) { + mImageView.setImageBitmap(bitmap); + } else { + mImageView.setImageResource(R.drawable.image_placeholder); + BitmapWorkerTask task = new BitmapWorkerTask(mImageView); + task.execute(resId); + } + } + + ... // include updated BitmapWorkerTask from <a href="cache-bitmap.html#memory-cache">Use a Memory Cache</a> section +} +</pre> + +<p>Putting all these pieces together gives you a responsive {@link +android.support.v4.view.ViewPager} implementation with minimal image loading latency and the ability +to do as much or as little background processing on your images as needed.</p> + +<h2 id="gridview">Load Bitmaps into a GridView Implementation</h2> + +<p>The <a href="{@docRoot}design/building-blocks/grid-lists.html">grid list building block</a> is +useful for showing image data sets and can be implemented using a {@link android.widget.GridView} +component in which many images can be on-screen at any one time and many more need to be ready to +appear if the user scrolls up or down. When implementing this type of control, you must ensure the +UI remains fluid, memory usage remains under control and concurrency is handled correctly (due to +the way {@link android.widget.GridView} recycles its children views).</p> + +<p>To start with, here is a standard {@link android.widget.GridView} implementation with {@link +android.widget.ImageView} children placed inside a {@link android.app.Fragment}:</p> + +<pre> +public class ImageGridFragment extends Fragment implements AdapterView.OnItemClickListener { + private ImageAdapter mAdapter; + + // A static dataset to back the GridView adapter + public final static Integer[] imageResIds = new Integer[] { + R.drawable.sample_image_1, R.drawable.sample_image_2, R.drawable.sample_image_3, + R.drawable.sample_image_4, R.drawable.sample_image_5, R.drawable.sample_image_6, + R.drawable.sample_image_7, R.drawable.sample_image_8, R.drawable.sample_image_9}; + + // Empty constructor as per Fragment docs + public ImageGridFragment() {} + + @Override + public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + mAdapter = new ImageAdapter(getActivity()); + } + + @Override + public View onCreateView( + LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { + final View v = inflater.inflate(R.layout.image_grid_fragment, container, false); + final GridView mGridView = (GridView) v.findViewById(R.id.gridView); + mGridView.setAdapter(mAdapter); + mGridView.setOnItemClickListener(this); + return v; + } + + @Override + public void onItemClick(AdapterView<?> parent, View v, int position, long id) { + final Intent i = new Intent(getActivity(), ImageDetailActivity.class); + i.putExtra(ImageDetailActivity.EXTRA_IMAGE, position); + startActivity(i); + } + + private class ImageAdapter extends BaseAdapter { + private final Context mContext; + + public ImageAdapter(Context context) { + super(); + mContext = context; + } + + @Override + public int getCount() { + return imageResIds.length; + } + + @Override + public Object getItem(int position) { + return imageResIds[position]; + } + + @Override + public long getItemId(int position) { + return position; + } + + @Override + public View getView(int position, View convertView, ViewGroup container) { + ImageView imageView; + if (convertView == null) { // if it's not recycled, initialize some attributes + imageView = new ImageView(mContext); + imageView.setScaleType(ImageView.ScaleType.CENTER_CROP); + imageView.setLayoutParams(new GridView.LayoutParams( + LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT)); + } else { + imageView = (ImageView) convertView; + } + <strong>imageView.setImageResource(imageResIds[position]);</strong> // Load image into ImageView + return imageView; + } + } +} +</pre> + +<p>Once again, the problem with this implementation is that the image is being set in the UI thread. +While this may work for small, simple images (due to system resource loading and caching), if any +additional processing needs to be done, your UI grinds to a halt.</p> + +<p>The same asynchronous processing and caching methods from the previous section can be implemented +here. However, you also need to wary of concurrency issues as the {@link android.widget.GridView} +recycles its children views. To handle this, use the techniques discussed in the <a +href="process-bitmap#concurrency">Processing Bitmaps Off the UI Thread</a> lesson. Here is the updated +solution:</p> + +<pre> +public class ImageGridFragment extends Fragment implements AdapterView.OnItemClickListener { + ... + + private class ImageAdapter extends BaseAdapter { + ... + + @Override + public View getView(int position, View convertView, ViewGroup container) { + ... + <strong>loadBitmap(imageResIds[position], imageView)</strong> + return imageView; + } + } + + public void loadBitmap(int resId, ImageView imageView) { + if (cancelPotentialWork(resId, imageView)) { + final BitmapWorkerTask task = new BitmapWorkerTask(imageView); + final AsyncDrawable asyncDrawable = + new AsyncDrawable(getResources(), mPlaceHolderBitmap, task); + imageView.setImageDrawable(asyncDrawable); + task.execute(resId); + } + } + + static class AsyncDrawable extends BitmapDrawable { + private final WeakReference<BitmapWorkerTask> bitmapWorkerTaskReference; + + public AsyncDrawable(Resources res, Bitmap bitmap, + BitmapWorkerTask bitmapWorkerTask) { + super(res, bitmap); + bitmapWorkerTaskReference = + new WeakReference<BitmapWorkerTask>(bitmapWorkerTask); + } + + public BitmapWorkerTask getBitmapWorkerTask() { + return bitmapWorkerTaskReference.get(); + } + } + + public static boolean cancelPotentialWork(int data, ImageView imageView) { + final BitmapWorkerTask bitmapWorkerTask = getBitmapWorkerTask(imageView); + + if (bitmapWorkerTask != null) { + final int bitmapData = bitmapWorkerTask.data; + if (bitmapData != data) { + // Cancel previous task + bitmapWorkerTask.cancel(true); + } else { + // The same work is already in progress + return false; + } + } + // No task associated with the ImageView, or an existing task was cancelled + return true; + } + + private static BitmapWorkerTask getBitmapWorkerTask(ImageView imageView) { + if (imageView != null) { + final Drawable drawable = imageView.getDrawable(); + if (drawable instanceof AsyncDrawable) { + final AsyncDrawable asyncDrawable = (AsyncDrawable) drawable; + return asyncDrawable.getBitmapWorkerTask(); + } + } + return null; + } + + ... // include updated <a href="process-bitmap.html#BitmapWorkerTaskUpdated">{@code BitmapWorkerTask}</a> class +</pre> + +<p class="note"><strong>Note:</strong> The same code can easily be adapted to work with {@link +android.widget.ListView} as well.</p> + +<p>This implementation allows for flexibility in how the images are processed and loaded without +impeding the smoothness of the UI. In the background task you can load images from the network or +resize large digital camera photos and the images appear as the tasks finish processing.</p> + +<p>For a full example of this and other concepts discussed in this lesson, please see the included +sample application.</p> diff --git a/docs/html/training/displaying-bitmaps/index.jd b/docs/html/training/displaying-bitmaps/index.jd new file mode 100644 index 0000000..6755c24 --- /dev/null +++ b/docs/html/training/displaying-bitmaps/index.jd @@ -0,0 +1,78 @@ +page.title=Displaying Bitmaps Efficiently + +trainingnavtop=true +startpage=true +next.title=Loading Large Bitmaps Efficiently +next.link=load-bitmap.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>Dependencies and prerequisites</h2> +<ul> + <li>Android 2.1 (API Level 7) or higher</li> + <li><a href="{@docRoot}sdk/compatibility-library.html">Support Library</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> + <a href="{@docRoot}shareables/training/BitmapFun.zip" class="button">Download the sample</a> + <p class="filename">BitmapFun.zip</p> +</div> + +</div> +</div> + +<p>This class covers some common techniques for processing and loading {@link +android.graphics.Bitmap} objects in a way that keeps your user interface (UI) components responsive +and avoids exceeding your application memory limit. If you're not careful, bitmaps can quickly +consume your available memory budget leading to an application crash due to the dreaded +exception:<br />{@code java.lang.OutofMemoryError: bitmap size exceeds VM budget}.</p> + +<p>There are a number of reasons why loading bitmaps in your Android application is tricky:</p> + +<ul> + <li>Mobile devices typically have constrained system resources. Android devices can have as little + as 16MB of memory available to a single application. The <a + href="http://source.android.com/compatibility/downloads.html">Android Compatibility Definition + Document</a> (CDD), <i>Section 3.7. Virtual Machine Compatibility</i> gives the required minimum + application memory for various screen sizes and densities. Applications should be optimized to + perform under this minimum memory limit. However, keep in mind many devices are configured with + higher limits.</li> + <li>Bitmaps take up a lot of memory, especially for rich images like photographs. For example, the + camera on the <a href="http://www.google.com/nexus/">Galaxy Nexus</a> takes photos up to 2592x1936 + pixels (5 megapixels). If the bitmap configuration used is {@link + android.graphics.Bitmap.Config ARGB_8888} (the default from the Android 2.3 onward) then loading + this image into memory takes about 19MB of memory (2592*1936*4 bytes), immediately exhausting the + per-app limit on some devices.</li> + <li>Android app UI’s frequently require several bitmaps to be loaded at once. Components such as + {@link android.widget.ListView}, {@link android.widget.GridView} and {@link + android.support.v4.view.ViewPager} commonly include multiple bitmaps on-screen at once with many + more potentially off-screen ready to show at the flick of a finger.</li> +</ul> + +<h2>Lessons</h2> + +<dl> + <dt><b><a href="load-bitmap.html">Loading Large Bitmaps Efficiently</a></b></dt> + <dd>This lesson walks you through decoding large bitmaps without exceeding the per application + memory limit.</dd> + + <dt><b><a href="process-bitmap.html">Processing Bitmaps Off the UI Thread</a></b></dt> + <dd>Bitmap processing (resizing, downloading from a remote source, etc.) should never take place + on the main UI thread. This lesson walks you through processing bitmaps in a background thread + using {@link android.os.AsyncTask} and explains how to handle concurrency issues.</dd> + + <dt><b><a href="cache-bitmap.html">Caching Bitmaps</a></b></dt> + <dd>This lesson walks you through using a memory and disk bitmap cache to improve the + responsiveness and fluidity of your UI when loading multiple bitmaps.</dd> + + <dt><b><a href="display-bitmap.html">Displaying Bitmaps in Your UI</a></b></dt> + <dd>This lesson brings everything together, showing you how to load multiple bitmaps into + components like {@link android.support.v4.view.ViewPager} and {@link android.widget.GridView} + using a background thread and bitmap cache.</dd> + +</dl>
\ No newline at end of file diff --git a/docs/html/training/displaying-bitmaps/load-bitmap.jd b/docs/html/training/displaying-bitmaps/load-bitmap.jd new file mode 100644 index 0000000..c0a5709 --- /dev/null +++ b/docs/html/training/displaying-bitmaps/load-bitmap.jd @@ -0,0 +1,165 @@ +page.title=Loading Large Bitmaps Efficiently +parent.title=Displaying Bitmaps Efficiently +parent.link=index.html + +trainingnavtop=true +next.title=Processing Bitmaps Off the UI Thread +next.link=process-bitmap.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#read-bitmap">Read Bitmap Dimensions and Type</a></li> + <li><a href="#load-bitmap">Load a Scaled Down Version into Memory</a></li> +</ol> + +<h2>Try it out</h2> + +<div class="download-box"> + <a href="{@docRoot}shareables/training/BitmapFun.zip" class="button">Download the sample</a> + <p class="filename">BitmapFun.zip</p> +</div> + +</div> +</div> + +<p>Images come in all shapes and sizes. In many cases they are larger than required for a typical +application user interface (UI). For example, the system Gallery application displays photos taken +using your Android devices's camera which are typically much higher resolution than the screen +density of your device.</p> + +<p>Given that you are working with limited memory, ideally you only want to load a lower resolution +version in memory. The lower resolution version should match the size of the UI component that +displays it. An image with a higher resolution does not provide any visible benefit, but still takes +up precious memory and incurs additional performance overhead due to additional on the fly +scaling.</p> + +<p>This lesson walks you through decoding large bitmaps without exceeding the per application +memory limit by loading a smaller subsampled version in memory.</p> + +<h2 id="read-bitmap">Read Bitmap Dimensions and Type</h2> + +<p>The {@link android.graphics.BitmapFactory} class provides several decoding methods ({@link +android.graphics.BitmapFactory#decodeByteArray(byte[],int,int,android.graphics.BitmapFactory.Options) +decodeByteArray()}, {@link +android.graphics.BitmapFactory#decodeFile(java.lang.String,android.graphics.BitmapFactory.Options) +decodeFile()}, {@link +android.graphics.BitmapFactory#decodeResource(android.content.res.Resources,int,android.graphics.BitmapFactory.Options) +decodeResource()}, etc.) for creating a {@link android.graphics.Bitmap} from various sources. Choose +the most appropriate decode method based on your image data source. These methods attempt to +allocate memory for the constructed bitmap and therefore can easily result in an {@code OutOfMemory} +exception. Each type of decode method has additional signatures that let you specify decoding +options via the {@link android.graphics.BitmapFactory.Options} class. Setting the {@link +android.graphics.BitmapFactory.Options#inJustDecodeBounds} property to {@code true} while decoding +avoids memory allocation, returning {@code null} for the bitmap object but setting {@link +android.graphics.BitmapFactory.Options#outWidth}, {@link +android.graphics.BitmapFactory.Options#outHeight} and {@link +android.graphics.BitmapFactory.Options#outMimeType}. This technique allows you to read the +dimensions and type of the image data prior to construction (and memory allocation) of the +bitmap.</p> + +<pre> +BitmapFactory.Options options = new BitmapFactory.Options(); +options.inJustDecodeBounds = true; +BitmapFactory.decodeResource(getResources(), R.id.myimage, options); +int imageHeight = options.outHeight; +int imageWidth = options.outWidth; +String imageType = options.outMimeType; +</pre> + +<p>To avoid {@code java.lang.OutOfMemory} exceptions, check the dimensions of a bitmap before +decoding it, unless you absolutely trust the source to provide you with predictably sized image data +that comfortably fits within the available memory.</p> + +<h2 id="load-bitmap">Load a Scaled Down Version into Memory</h2> + +<p>Now that the image dimensions are known, they can be used to decide if the full image should be +loaded into memory or if a subsampled version should be loaded instead. Here are some factors to +consider:</p> + +<ul> + <li>Estimated memory usage of loading the full image in memory.</li> + <li>Amount of memory you are willing to commit to loading this image given any other memory + requirements of your application.</li> + <li>Dimensions of the target {@link android.widget.ImageView} or UI component that the image + is to be loaded into.</li> + <li>Screen size and density of the current device.</li> +</ul> + +<p>For example, it’s not worth loading a 1024x768 pixel image into memory if it will eventually be +displayed in a 128x96 pixel thumbnail in an {@link android.widget.ImageView}.</p> + +<p>To tell the decoder to subsample the image, loading a smaller version into memory, set {@link +android.graphics.BitmapFactory.Options#inSampleSize} to {@code true} in your {@link +android.graphics.BitmapFactory.Options} object. For example, an image with resolution 2048x1536 that +is decoded with an {@link android.graphics.BitmapFactory.Options#inSampleSize} of 4 produces a +bitmap of approximately 512x384. Loading this into memory uses 0.75MB rather than 12MB for the full +image (assuming a bitmap configuration of {@link android.graphics.Bitmap.Config ARGB_8888}). Here’s +a method to calculate a the sample size value based on a target width and height:</p> + +<pre> +public static int calculateInSampleSize( + BitmapFactory.Options options, int reqWidth, int reqHeight) { + // Raw height and width of image + final int height = options.outHeight; + final int width = options.outWidth; + int inSampleSize = 1; + + if (height > reqHeight || width > reqWidth) { + if (width > height) { + inSampleSize = Math.round((float)height / (float)reqHeight); + } else { + inSampleSize = Math.round((float)width / (float)reqWidth); + } + } + return inSampleSize; +} +</pre> + +<p class="note"><strong>Note:</strong> Using powers of 2 for {@link +android.graphics.BitmapFactory.Options#inSampleSize} values is faster and more efficient for the +decoder. However, if you plan to cache the resized versions in memory or on disk, it’s usually still +worth decoding to the most appropriate image dimensions to save space.</p> + +<p>To use this method, first decode with {@link +android.graphics.BitmapFactory.Options#inJustDecodeBounds} set to {@code true}, pass the options +through and then decode again using the new {@link +android.graphics.BitmapFactory.Options#inSampleSize} value and {@link +android.graphics.BitmapFactory.Options#inJustDecodeBounds} set to {@code false}:</p> + +<a name="decodeSampledBitmapFromResource"></a> +<pre> +public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId, + int reqWidth, int reqHeight) { + + // First decode with inJustDecodeBounds=true to check dimensions + final BitmapFactory.Options options = new BitmapFactory.Options(); + options.inJustDecodeBounds = true; + BitmapFactory.decodeResource(res, resId, options); + + // Calculate inSampleSize + options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight); + + // Decode bitmap with inSampleSize set + options.inJustDecodeBounds = false; + return BitmapFactory.decodeResource(res, resId, options); +} +</pre> + +<p>This method makes it easy to load a bitmap of arbitrarily large size into an {@link +android.widget.ImageView} that displays a 100x100 pixel thumbnail, as shown in the following example +code:</p> + +<pre> +mImageView.setImageBitmap( + decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100)); +</pre> + +<p>You can follow a similar process to decode bitmaps from other sources, by substituting the +appropriate {@link +android.graphics.BitmapFactory#decodeByteArray(byte[],int,int,android.graphics.BitmapFactory.Options) +BitmapFactory.decode*} method as needed.</p>
\ No newline at end of file diff --git a/docs/html/training/displaying-bitmaps/process-bitmap.jd b/docs/html/training/displaying-bitmaps/process-bitmap.jd new file mode 100644 index 0000000..c1450b4 --- /dev/null +++ b/docs/html/training/displaying-bitmaps/process-bitmap.jd @@ -0,0 +1,239 @@ +page.title=Processing Bitmaps Off the UI Thread +parent.title=Displaying Bitmaps Efficiently +parent.link=index.html + +trainingnavtop=true +next.title=Caching Bitmaps +next.link=cache-bitmap.html +previous.title=Loading Large Bitmaps Efficiently +previous.link=load-bitmap.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#async-task">Use an AsyncTask</a></li> + <li><a href="#concurrency">Handle Concurrency</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/practices/design/responsiveness.html">Designing for Responsiveness</a></li> + <li><a + href="http://android-developers.blogspot.com/2010/07/multithreading-for-performance.html">Multithreading + for Performance</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> + <a href="{@docRoot}shareables/training/BitmapFun.zip" class="button">Download the sample</a> + <p class="filename">BitmapFun.zip</p> +</div> + +</div> +</div> + +<p>The {@link +android.graphics.BitmapFactory#decodeByteArray(byte[],int,int,android.graphics.BitmapFactory.Options) +BitmapFactory.decode*} methods, discussed in the <a href="load-bitmap.html">Load Large Bitmaps +Efficiently</a> lesson, should not be executed on the main UI thread if the source data is read from +disk or a network location (or really any source other than memory). The time this data takes to +load is unpredictable and depends on a variety of factors (speed of reading from disk or network, +size of image, power of CPU, etc.). If one of these tasks blocks the UI thread, the system flags +your application as non-responsive and the user has the option of closing it (see <a +href="{@docRoot}guide/practices/design/responsiveness.html">Designing for Responsiveness</a> for +more information).</p> + +<p>This lesson walks you through processing bitmaps in a background thread using +{@link android.os.AsyncTask} and shows you how to handle concurrency issues.</p> + +<h2 id="async-task">Use an AsyncTask</h2> + +<p>The {@link android.os.AsyncTask} class provides an easy way to execute some work in a background +thread and publish the results back on the UI thread. To use it, create a subclass and override the +provided methods. Here’s an example of loading a large image into an {@link +android.widget.ImageView} using {@link android.os.AsyncTask} and <a +href="load-bitmap.html#decodeSampledBitmapFromResource">{@code +decodeSampledBitmapFromResource()}</a>: </p> + +<a name="BitmapWorkerTask"></a> +<pre> +class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> { + private final WeakReference<ImageView> imageViewReference; + private int data = 0; + + public BitmapWorkerTask(ImageView imageView) { + // Use a WeakReference to ensure the ImageView can be garbage collected + imageViewReference = new WeakReference<ImageView>(imageView); + } + + // Decode image in background. + @Override + protected Bitmap doInBackground(Integer... params) { + data = params[0]; + return decodeSampledBitmapFromResource(getResources(), data, 100, 100)); + } + + // Once complete, see if ImageView is still around and set bitmap. + @Override + protected void onPostExecute(Bitmap bitmap) { + if (imageViewReference != null && bitmap != null) { + final ImageView imageView = imageViewReference.get(); + if (imageView != null) { + imageView.setImageBitmap(bitmap); + } + } + } +} +</pre> + +<p>The {@link java.lang.ref.WeakReference} to the {@link android.widget.ImageView} ensures that the +{@link android.os.AsyncTask} does not prevent the {@link android.widget.ImageView} and anything it +references from being garbage collected. There’s no guarantee the {@link android.widget.ImageView} +is still around when the task finishes, so you must also check the reference in {@link +android.os.AsyncTask#onPostExecute(Result) onPostExecute()}. The {@link android.widget.ImageView} +may no longer exist, if for example, the user navigates away from the activity or if a +configuration change happens before the task finishes.</p> + +<p>To start loading the bitmap asynchronously, simply create a new task and execute it:</p> + +<pre> +public void loadBitmap(int resId, ImageView imageView) { + BitmapWorkerTask task = new BitmapWorkerTask(imageView); + task.execute(resId); +} +</pre> + +<h2 id="concurrency">Handle Concurrency</h2> + +<p>Common view components such as {@link android.widget.ListView} and {@link +android.widget.GridView} introduce another issue when used in conjunction with the {@link +android.os.AsyncTask} as demonstrated in the previous section. In order to be efficient with memory, +these components recycle child views as the user scrolls. If each child view triggers an {@link +android.os.AsyncTask}, there is no guarantee that when it completes, the associated view has not +already been recycled for use in another child view. Furthermore, there is no guarantee that the +order in which asynchronous tasks are started is the order that they complete.</p> + +<p>The blog post <a +href="http://android-developers.blogspot.com/2010/07/multithreading-for-performance.html">Multithreading +for Performance</a> further discusses dealing with concurrency, and offers a solution where the +{@link android.widget.ImageView} stores a reference to the most recent {@link android.os.AsyncTask} +which can later be checked when the task completes. Using a similar method, the {@link +android.os.AsyncTask} from the previous section can be extended to follow a similar pattern.</p> + +<p>Create a dedicated {@link android.graphics.drawable.Drawable} subclass to store a reference +back to the worker task. In this case, a {@link android.graphics.drawable.BitmapDrawable} is used so +that a placeholder image can be displayed in the {@link android.widget.ImageView} while the task +completes:</p> + +<a name="AsyncDrawable"></a> +<pre> +static class AsyncDrawable extends BitmapDrawable { + private final WeakReference<BitmapWorkerTask> bitmapWorkerTaskReference; + + public AsyncDrawable(Resources res, Bitmap bitmap, + BitmapWorkerTask bitmapWorkerTask) { + super(res, bitmap); + bitmapWorkerTaskReference = + new WeakReference<BitmapWorkerTask>(bitmapWorkerTask); + } + + public BitmapWorkerTask getBitmapWorkerTask() { + return bitmapWorkerTaskReference.get(); + } +} +</pre> + +<p>Before executing the <a href="#BitmapWorkerTask">{@code BitmapWorkerTask}</a>, you create an <a +href="#AsyncDrawable">{@code AsyncDrawable}</a> and bind it to the target {@link +android.widget.ImageView}:</p> + +<pre> +public void loadBitmap(int resId, ImageView imageView) { + if (cancelPotentialWork(resId, imageView)) { + final BitmapWorkerTask task = new BitmapWorkerTask(imageView); + final AsyncDrawable asyncDrawable = + new AsyncDrawable(getResources(), mPlaceHolderBitmap, task); + imageView.setImageDrawable(asyncDrawable); + task.execute(resId); + } +} +</pre> + +<p>The {@code cancelPotentialWork} method referenced in the code sample above checks if another +running task is already associated with the {@link android.widget.ImageView}. If so, it attempts to +cancel the previous task by calling {@link android.os.AsyncTask#cancel cancel()}. In a small number +of cases, the new task data matches the existing task and nothing further needs to happen. Here is +the implementation of {@code cancelPotentialWork}:</p> + +<pre> +public static boolean cancelPotentialWork(int data, ImageView imageView) { + final BitmapWorkerTask bitmapWorkerTask = getBitmapWorkerTask(imageView); + + if (bitmapWorkerTask != null) { + final int bitmapData = bitmapWorkerTask.data; + if (bitmapData != data) { + // Cancel previous task + bitmapWorkerTask.cancel(true); + } else { + // The same work is already in progress + return false; + } + } + // No task associated with the ImageView, or an existing task was cancelled + return true; +} +</pre> + +<p>A helper method, {@code getBitmapWorkerTask()}, is used above to retrieve the task associated +with a particular {@link android.widget.ImageView}:</p> + +<pre> +private static BitmapWorkerTask getBitmapWorkerTask(ImageView imageView) { + if (imageView != null) { + final Drawable drawable = imageView.getDrawable(); + if (drawable instanceof AsyncDrawable) { + final AsyncDrawable asyncDrawable = (AsyncDrawable) drawable; + return asyncDrawable.getBitmapWorkerTask(); + } + } + return null; +} +</pre> + +<p>The last step is updating {@code onPostExecute()} in <a href="#BitmapWorkerTask">{@code +BitmapWorkerTask}</a> so that it checks if the task is cancelled and if the current task matches the +one associated with the {@link android.widget.ImageView}:</p> + +<a name="BitmapWorkerTaskUpdated"></a> +<pre> +class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> { + ... + + @Override + protected void onPostExecute(Bitmap bitmap) { + <strong>if (isCancelled()) { + bitmap = null; + }</strong> + + if (imageViewReference != null && bitmap != null) { + final ImageView imageView = imageViewReference.get(); + <strong>final BitmapWorkerTask bitmapWorkerTask = + getBitmapWorkerTask(imageView);</strong> + if (<strong>this == bitmapWorkerTask &&</strong> imageView != null) { + imageView.setImageBitmap(bitmap); + } + } + } +} +</pre> + +<p>This implementation is now suitable for use in {@link android.widget.ListView} and {@link +android.widget.GridView} components as well as any other components that recycle their child +views. Simply call {@code loadBitmap} where you normally set an image to your {@link +android.widget.ImageView}. For example, in a {@link android.widget.GridView} implementation this +would be in the {@link android.widget.Adapter#getView getView()} method of the backing adapter.</p>
\ No newline at end of file diff --git a/docs/html/training/efficient-downloads/connectivity_patterns.jd b/docs/html/training/efficient-downloads/connectivity_patterns.jd new file mode 100644 index 0000000..81f1540 --- /dev/null +++ b/docs/html/training/efficient-downloads/connectivity_patterns.jd @@ -0,0 +1,76 @@ +page.title=Modifying your Download Patterns Based on the Connectivity Type +parent.title=Transferring Data Without Draining the Battery +parent.link=index.html + +trainingnavtop=true +previous.title=Redundant Downloads are Redundant +previous.link=redundant_redundant.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#WiFi">Use Wi-Fi</a></li> + <li><a href="#Bandwidth">Use greater bandwidth to download more data less often</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/monitoring-device-state/index.html">Optimizing Battery Life</a></li> +</ul> + +</div> +</div> + +<p>When it comes to impact on battery life, not all connection types are created equal. Not only does the Wi-Fi radio use significantly less battery than its wireless radio counterparts, but the radios used in different wireless radio technologies have different battery implications.</p> + +<h2 id="WiFi">Use Wi-Fi</h2> + +<p>In most cases a Wi-Fi radio will offer greater bandwidth at a significantly lower battery cost. As a result, you should endeavor to perform data transfers when connected over Wi-Fi whenever possible.</p> + +<p>You can use a broadcast receiver to listen for connectivity changes that indicate when a Wi-Fi connection has been established to execute significant downloads, preempt scheduled updates, and potentially even temporarily increase the frequency of regular updates as described in <a href="{@docRoot}training/monitoring-device-state/index.html">Optimizing Battery Life</a> lesson <a href="{@docRoot}training/monitoring-device-state/connectivity-monitoring.html">Determining and Monitoring the Connectivity Status</a>.</p> + +<h2 id="Bandwidth">Use Greater Bandwidth to Download More Data Less Often</h2> + +<p>When connected over a wireless radio, higher bandwidth generally comes at the price of higher battery cost. Meaning that LTE typically consumes more energy than 3G, which is in turn more expensive than 2G.</p> + +<p>This means that while the underlying radio state machine varies based on the radio technology, generally speaking the relative battery impact of the state change tail-time is greater for higher bandwidth radios.</p> + +<p>At the same time, the higher bandwidth means you can prefetch more aggressively, downloading more data over the same time. Perhaps less intuitively, because the tail-time battery cost is relatively higher, it's also more efficient to keep the radio active for longer periods during each transfer session to reduce the frequency of updates.</p> + +<p>For example, if an LTE radio is has double the bandwidth and double the energy cost of 3G, you should download 4 times as much data during each session—or potentially as much as 10mb. When downloading this much data, it's important to consider the effect of your prefetching on the available local storage and flush your prefetch cache regularly.</p> + +<p>You can use the connectivity manager to determine the active wireless radio, and modify your prefetching routines accordingly:</p> + +<pre>ConnectivityManager cm = + (ConnectivityManager)getSystemService(Context.CONNECTIVITY_SERVICE); + +TelephonyManager tm = + (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE); + +NetworkInfo activeNetwork = cm.getActiveNetworkInfo(); + +int PrefetchCacheSize = DEFAULT_PREFETCH_CACHE; + +switch (activeNetwork.getType()) { + case (ConnectivityManager.TYPE_WIFI): + PrefetchCacheSize = MAX_PREFETCH_CACHE; break; + case (ConnectivityManager.TYPE_MOBILE): { + switch (tm.getNetworkType()) { + case (TelephonyManager.NETWORK_TYPE_LTE | + TelephonyManager.NETWORK_TYPE_HSPAP): + PrefetchCacheSize *= 4; + break; + case (TelephonyManager.NETWORK_TYPE_EDGE | + TelephonyManager.NETWORK_TYPE_GPRS): + PrefetchCacheSize /= 2; + break; + default: break; + } + break; + } + default: break; +}</pre>
\ No newline at end of file diff --git a/docs/html/training/efficient-downloads/efficient-network-access.jd b/docs/html/training/efficient-downloads/efficient-network-access.jd new file mode 100644 index 0000000..0efad7d --- /dev/null +++ b/docs/html/training/efficient-downloads/efficient-network-access.jd @@ -0,0 +1,170 @@ +page.title=Optimizing Downloads for Efficient Network Access +parent.title=Transferring Data Without Draining the Battery +parent.link=index.html + +trainingnavtop=true +next.title=Minimizing the Effect of Regular Updates +next.link=regular_updates.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#RadioStateMachine">Understand the radio state machine</a></li> + <li><a href="#AppsStateMachine">Understand how apps can impact the radio state machine</a></li> + <li><a href="#PrefetchData">Efficiently prefetch data</a></li> + <li><a href="#BatchTransfers">Batch transfers and connections</a></li> + <li><a href="#ReduceConnections">Reduce the number of connections you use</a></li> + <li><a href="#DDMSNetworkTraffic">Use the DDMS Network Traffic Tool to identify areas of concern</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/monitoring-device-state/index.html">Optimizing Battery Life</a></li> +</ul> + +</div> +</div> + +<p>Using the wireless radio to transfer data is potentially one of your app's most significant sources of battery drain. To minimize the battery drain associated with network activity, it's critical that you understand how your connectivity model will affect the underlying radio hardware.</p> + +<p>This lesson introduces the wireless radio state machine and explains how your app's connectivity model interacts with it. It goes on to propose ways to minimize your data connections, use prefetching, and bundle your transfers in order to minimize the battery drain associated with your data transfers.</p> + +<h2 id="RadioStateMachine">The Radio State Machine</h2> + +<p>A fully active wireless radio consumes significant power, so it transitions between different energy states in order to conserve power when not in use, while attempting to minimize latency associated with "powering up" the radio when it's required.</p> + +<p>The state machine for a typical 3G network radio consists of three energy states: +<ol><li><b>Full power</b>: Used when a connection is active, allowing the device to transfer data at its highest possible rate.</li> +<li><b>Low power</b>: An intermediate state that uses around 50% of the battery power at the full state.</li> +<li><b>Standby</b>: The minimal energy state during which no network connection is active or required.</li> +</ol></p> + +<p>While the low and idle states drain significantly less battery, they also introduce significant latency to network requests. Returning to full power from the low state takes around 1.5 seconds, while moving from idle to full can take over 2 seconds.</p> + +<p>To minimize latency, the state machine uses a delay to postpone the transition to lower energy states. Figure 1 uses AT&T's timings for a typical 3G radio.</p> + +<img src="{@docRoot}images/efficient-downloads/mobile_radio_state_machine.png" /> +<p class="img-caption"><strong>Figure 1.</strong> Typical 3G wireless radio state machine.</p> + +<p>The radio state machine on each device, particularly the associated transition delay ("tail time") and startup latency, will vary based on the wireless radio technology employed (2G, 3G, LTE, etc.) and is defined and configured by the carrier network over which the device is operating.</p> + +<p>This lesson describes a representative state machine for a typical 3G wireless radio, based on <a href="http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=1zObBOMOZSB">data provided by AT&T</a>. However, the general principles and resulting best practices are applicable for all wireless radio implementations.</p> + +<p>This approach is particularly effective for typical web browsing as it prevents unwelcome latency while users browse the web. The relatively low tail-time also ensures that once a browsing session has finished, the radio can move to a lower energy state.</p> + +<p>Unfortunately, this approach can lead to inefficient apps on modern smartphone OSs like Android, where apps run both in the foreground (where latency is important) and in the background (where battery life should be prioritized).</p> + +<h2 id="AppsStateMachine">How Apps Impact the Radio State Machine</h2> + +<p>Every time you create a new network connection, the radio transitions to the full power state. In the case of the typical 3G radio state machine described above, it will remain at full power for the duration of your transfer—plus an additional 5 seconds of tail time—followed by 12 seconds at the low energy state. So for a typical 3G device, every data transfer session will cause the radio to draw energy for almost 20 seconds.</p> + +<p>In practice, this means an app that transfers unbundled data for 1 second every 18 seconds will keep the wireless radio perpetually active, moving it back to high power just as it was about to become idle. As a result, every minute it will consume battery at the high power state for 18 seconds, and at the low power state for the remaining 42 seconds.</p> + +<p>By comparison, the same app that bundles transfers of 3 seconds of every minute will keep the radio in the high power state for only 8 seconds, and will keep it in the low power state for only an additional 12 seconds.</p> + +<p>The second example allows the radio to be idle for an additional 40 second every minute, resulting in a massive reduction in battery consumption.</p> + +<img src="{@docRoot}images/efficient-downloads/graphs.png" /> +<p class="img-caption"><strong>Figure 2.</strong> Relative wireless radio power use for bundled versus unbundled transfers.</p> + +<h2 id="PrefetchData">Prefetch Data</h2> + +<p>Prefetching data is an effective way to reduce the number of independent data transfer sessions. Prefetching allows you to download all the data you are likely to need for a given time period in a single burst, over a single connection, at full capacity.</p> + +<p>By front loading your transfers, you reduce the number of radio activations required to download the data. As a result you not only conserve battery life, but also improve the latency, lower the required bandwidth, and reduce download times.</p> + +<p>Prefetching also provides an improved user experience by minimizing in-app latency caused by waiting for downloads to complete before performing an action or viewing data.</p> + +<p>However, used too aggressively, prefetching introduces the risk of increasing battery drain and bandwidth use—as well as download quota—by downloading data that isn't used. It's also important to ensure that prefetching doesn't delay application startup while the app waits for the prefetch to complete. In practical terms that might mean processing data progressively, or initiating consecutive transfers prioritized such that the data required for application startup is downloaded and processed first.</p> + +<p>How aggressively you prefetch depends on the size of the data being downloaded and the likelihood of it being used. As a rough guide, based on the state machine described above, for data that has a 50% chance of being used within the current user session, you can typically prefetch for around 6 seconds (approximately 1-2 Mb) before the potential cost of downloading unused data matches the potential savings of not downloading that data to begin with.</p> + +<p>Generally speaking, it's good practice to prefetch data such that you will only need to initiate another download every 2 to 5 minutes, and in the order of 1 to 5 megabytes.</p> + +<p>Following this principle, large downloads—such as video files—should be downloaded in chunks at regular intervals (every 2 to 5 minutes), effectively prefetching only the video data likely to be viewed in the next few minutes.</p> + +<p>Note that further downloads should be bundled, as described in the next section, <a href="#BatchTransfers">Batch Transfers and Connections</a>, and that these approximations will vary based on the connection type and speed, as discussed in <a href="connectivity_patterns.html">Modify your Download Patterns Based on the Connectivity Type</a>.</p> + +<p>Let's look at some practical examples:</p> + +<p><b>A music player</b></p> + +<p>You could choose to prefetch an entire album, however should the user stop listening after the first song, you've wasted a significant amount of bandwidth and battery life.</p> + +<p>A better approach would be to maintain a buffer of one song in addition to the one being played. For streaming music, rather than maintaining a continuous stream that keeps the radio active at all times, consider using HTTP live streaming to transmit the audio stream in bursts, simulating the prefetching approach described above.</p> + +<p><b>A news reader</b></p> + +<p>Many news apps attempt to reduce bandwidth by downloading headlines only after a category has been selected, full articles only when the user wants to read them, and thumbnails just as they scroll into view.</p> + +<p>Using this approach, the radio will be forced to remain active for the majority of users' news-reading session as they scroll headlines, change categories, and read articles. Not only that, but the constant switching between energy states will result in significant latency when switching categories or reading articles.</p> + +<p>A better approach would be to prefetch a reasonable amount of data at startup, beginning with the first set of news headlines and thumbnails—ensuring a low latency startup time—and continuing with the remaining headlines and thumbnails, as well as the article text for each article available from at least the primary headline list.</p> + +<p>Another alternative is to prefetch every headline, thumbnail, article text, and possibly even full article pictures—typically in the background on a predetermined schedule. This approach risks spending significant bandwidth and battery life downloading content that's never used, so it should be implemented with caution.</p> + +<p>One solution is to schedule the full download to occur only when connected to Wi-Fi, and possibly only when the device is charging. This is investigated in more detail in <a href="connectivity_patterns.html">Modify your Download Patterns Based on the Connectivity Type</a>.</p> + +<h2 id="BatchTransfers">Batch Transfers and Connections</h2> + +Every time you initiate a connection—irrespective of the size of the associated data transfer—you potentially cause the radio to draw power for nearly 20 seconds when using a typical 3G wireless radio.</p> + +<p>An app that pings the server every 20 seconds, just to acknowledge that the app is running and visible to the user, will keep the radio powered on indefinitely, resulting in a significant battery cost for almost no actual data transfer.</p> + +<p>With that in mind it's important to bundle your data transfers and create a pending transfer queue. Done correctly, you can effectively phase-shift transfers that are due to occur within a similar time window, to make them all happen simultaneously—ensuring that the radio draws power for as short a duration as possible.</p> + +<p>The underlying philosophy of this approach is to transfer as much data as possible during each transfer session in an effort to limit the number of sessions you require.</p> + +<p>That means you should batch your transfers by queuing delay tolerant transfers, and preempting scheduled updates and prefetches, so that they are all executed when time-sensitive transfers are required. Similarly, your scheduled updates and regular prefetching should initiate the execution of your pending transfer queue.</p> + +<p>For a practical example, let's return to the earlier examples from <a href="#PrefetchData">Prefetch Data</a>.</p> + +<p>Take a news application that uses the prefetching routine described above. The news reader collects analytics information to understand the reading patterns of its users and to rank the most popular stories. To keep the news fresh, it checks for updates every hour. To conserve bandwidth, rather than download full photos for each article, it prefetches only thumbnails and downloads the full photos when they are selected.</p> + +<p>In this example, all the analytics information collected within the app should be bundled together and queued for download, rather than being transmitted as it's collected. The resulting bundle should be transferred when either a full-sized photo is being downloaded, or when an hourly update is being performed.</p> + +<p>Any time-sensitive or on-demand transfer—such as downloading a full-sized image—should preempt regularly scheduled updates. The planned update should be executed at the same time as the on-demand transfer, with the next update scheduled to occur after the set interval. This approach mitigates the cost of performing a regular update by piggy-backing on the necessary time-sensitive photo download.</p> + +<h2 id="ReduceConnections">Reduce Connections</h2> + +<p>It's generally more efficient to reuse existing network connections than to initiate new ones. Reusing connections also allows the network to more intelligently react to congestion and related network data issues.</p> + +<p>Rather than creating multiple simultaneous connections to download data, or chaining multiple consecutive GET requests, where possible you should bundle those requests into a single GET.</p> + +<p>For example, it would be more efficient to make a single request for every news article to be returned in a single request / response than to make multiple queries for several news categories. +The wireless radio needs to become active in order to transmit the termination / termination acknowledgement packets associated with server and client timeout, so it's also good practice to close your connections when they aren't in use, rather than waiting for these timeouts.</p> + +<p>That said, closing a connection too early can prevent it from being reused, which then requires additional overhead for establishing a new connection. A useful compromise is not to close the connection immediately, but to still close it before the inherent timeout expires.</p> + +<h2 id="DDMSNetworkTraffic">Use the DDMS Network Traffic Tool to Identify Areas of Concern</h2> + +<p>The Android <a href="{@docRoot}guide/developing/debugging/ddms.html">DDMS (Dalvik Debug Monitor Server)</a> includes a Detailed Network Usage tab that makes it possible to track when your application is making network requests. Using this tool, you can monitor how and when your app transfers data and optimize the underlying code appropriately.</p> + +<p>Figure 3 shows a pattern of transferring small amounts of data roughly 15 seconds apart, suggesting that efficiency could be dramatically improved by prefetching each request or bundling the uploads.</p> + +<img src="{@docRoot}images/efficient-downloads/DDMS.png" /> +<p class="img-caption"><strong>Figure 3.</strong> Tracking network usage with DDMS.</p> + +<p>By monitoring the frequency of your data transfers, and the amount of data transferred during each connection, you can identify areas of your application that can be made more battery-efficient. Generally, you will be looking for short spikes that can be delayed, or that should cause a later transfer to be preempted.</p> + +<p>To better identify the cause of transfer spikes, the Traffic Stats API allows you to tag the data transfers occurring within a thread using the {@code TrafficStats.setThreadStatsTag()} method, followed by manually tagging (and untagging) individual sockets using {@code tagSocket()} and {@code untagSocket()}. For example:</p> + +<pre>TrafficStats.setThreadStatsTag(0xF00D); +TrafficStats.tagSocket(outputSocket); +// Transfer data using socket +TrafficStats.untagSocket(outputSocket);</pre> + +<p>The Apache {@code HttpClient} and {@code URLConnection} libraries automatically tag sockets based on the current {@code getThreadStatsTag()} value. These libraries also tag and untag sockets when recycled through keep-alive pools.</p> + +<pre>TrafficStats.setThreadStatsTag(0xF00D); +try { + // Make network request using HttpClient.execute() +} finally { + TrafficStats.clearThreadStatsTag(); +}</pre> + +<p>Socket tagging is supported in Android 4.0, but real-time stats will only be displayed on devices running Android 4.0.3 or higher.</p>
\ No newline at end of file diff --git a/docs/html/training/efficient-downloads/index.jd b/docs/html/training/efficient-downloads/index.jd new file mode 100644 index 0000000..a29be91 --- /dev/null +++ b/docs/html/training/efficient-downloads/index.jd @@ -0,0 +1,51 @@ +page.title=Transferring Data Without Draining the Battery + +trainingnavtop=true +startpage=true +next.title=Optimizing Downloads for Efficient Network Access +next.link=efficient-network-access.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<!-- Required platform, tools, add-ons, devices, knowledge, etc. --> +<h2>Dependencies and prerequisites</h2> +<ul> + <li>Android 2.0 (API Level 5) or higher</li> +</ul> + +<!-- related docs (NOT javadocs) --> +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/monitoring-device-state/index.html">Optimizing Battery Life</a></li> +</ul> + +</div> +</div> + +<p>In this class you will learn to minimize the battery life impact of downloads and network connections, particularly in relation to the wireless radio.</P + +<p>This class demonstrates the best practices for scheduling and executing downloads using techniques such as caching, polling, and prefetching. You will learn how the power-use profile of the wireless radio can affect your choices on when, what, and how to transfer data in order to minimize impact on battery life.</p> + +<h2>Lessons</h2> + +<!-- Create a list of the lessons in this class along with a short description of each lesson. +These should be short and to the point. It should be clear from reading the summary whether someone +will want to jump to a lesson or not.--> + +<dl> + <dt><b><a href="efficient-network-access.html">Optimizing Downloads for Efficient Network Access</a></b></dt> + <dd>This lesson introduces the wireless radio state machine, explains how your app’s connectivity model interacts with it, and how you can minimize your data connection and use prefetching and bundling to minimize the battery drain associated with your data transfers.</dd> + + <dt><b><a href="regular_updates.html">Minimizing the Effect of Regular Updates</a></b></dt> + <dd>This lesson will examine how your refresh frequency can be varied to best mitigate the effect of background updates on the underlying wireless radio state machine.</dd> + + <dt><b><a href="redundant_redundant.html">Redundant Downloads are Redundant</a></b></dt> + <dd>The most fundamental way to reduce your downloads is to download only what you need. This lesson introduces some best practices to eliminate redundant downloads.</dd> + + <dt><b><a href="connectivity_patterns.html">Modifying your Download Patterns Based on the Connectivity Type</a></b></dt> + <dd>When it comes to impact on battery life, not all connection types are created equal. Not only does the Wi-Fi radio use significantly less battery than its wireless radio counterparts, but the radios used in different wireless radio technologies have different battery implications.</dd> + +</dl> diff --git a/docs/html/training/efficient-downloads/redundant_redundant.jd b/docs/html/training/efficient-downloads/redundant_redundant.jd new file mode 100644 index 0000000..4bf9af9 --- /dev/null +++ b/docs/html/training/efficient-downloads/redundant_redundant.jd @@ -0,0 +1,87 @@ +page.title=Redundant Downloads are Redundant +parent.title=Transferring Data Without Draining the Battery +parent.link=index.html + +trainingnavtop=true +previous.title=Minimizing the Effect of Regular Updates +previous.link=regular_updates.html +next.title=Connectivity Based Download Patterns +next.link=connectivity_patterns.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#LocalCache">Cache files locally</a></li> + <li><a href="#ResponseCache">Use the HttpURLConnection response cache</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/monitoring-device-state/index.html">Optimizing Battery Life</a></li> +</ul> + +</div> +</div> + +<p>The most fundamental way to reduce your downloads is to download only what you need. In terms of data, that means implementing REST APIs that allow you to specify query criteria that limit the returned data by using parameters such as the time of your last update.</p> + +<p>Similarly, when downloading images, it's good practice to reduce the size of the images server-side, rather than downloading full-sized images that are reduced on the client.</p> + +<h2 id="LocalCache">Cache Files Locally</h2> + +<p>Another important technique is to avoid downloading duplicate data. You can do this by aggressive caching. Always cache static resources, including on-demand downloads such as full size images, for as long as reasonably possible. On-demand resources should be stored separately to enable you to regularly flush your on-demand cache to manage its size.</p> + +<p>To ensure that your caching doesn't result in your app displaying stale data, be sure to extract the time at which the requested content was last updated, and when it expires, from within the HTTP response headers. This will allow you to determine when the associated content should be refreshed.</p> + +<pre>long currentTime = System.currentTimeMillis()); + +HttpURLConnection conn = (HttpURLConnection) url.openConnection(); + +long expires = conn.getHeaderFieldDate("Expires", currentTime); +long lastModified = conn.getHeaderFieldDate("Last-Modified", currentTime); + +setDataExpirationDate(expires); + +if (lastModified < lastUpdateTime) { + // Skip update +} else { + // Parse update +}</pre> + +<p>Using this approach, you can also effectively cache dynamic content while ensuring it doesn't result in your application displaying stale information.</p> + +<p>You can cache non-sensitive data can in the unmanaged external cache directory:</p> + +<pre>Context.getExternalCacheDir();</pre> + +<p>Alternatively, you can use the managed / secure application cache. Note that this internal cache may be flushed when the system is running low on available storage.</p> + +<pre>Context.getCache();</pre> + +<p>Files stored in either cache location will be erased when the application is uninstalled.</p> + +<h2 id="ResponseCache">Use the HttpURLConnection Response Cache</h2> + +<p>Android 4.0 added a response cache to {@code HttpURLConnection}. You can enable HTTP response caching on supported devices using reflection as follows:</p> + +<pre>private void enableHttpResponseCache() { + try { + long httpCacheSize = 10 * 1024 * 1024; // 10 MiB + File httpCacheDir = new File(getCacheDir(), "http"); + Class.forName("android.net.http.HttpResponseCache") + .getMethod("install", File.class, long.class) + .invoke(null, httpCacheDir, httpCacheSize); + } catch (Exception httpResponseCacheNotAvailable) { + Log.d(TAG, "HTTP response cache is unavailable."); + } +}</pre> + +<p>This sample code will turn on the response cache on Android 4.0+ devices without affecting earlier releases.</p> + +<p>With the cache installed, fully cached HTTP requests can be served directly from local storage, eliminating the need to open a network connection. Conditionally cached responses can validate their freshness from the server, eliminating the bandwidth cost associated with the download.</p> + +<p>Uncached responses get stored in the response cache for for future requests.</p>
\ No newline at end of file diff --git a/docs/html/training/efficient-downloads/regular_updates.jd b/docs/html/training/efficient-downloads/regular_updates.jd new file mode 100644 index 0000000..feb7a8e --- /dev/null +++ b/docs/html/training/efficient-downloads/regular_updates.jd @@ -0,0 +1,102 @@ +page.title=Minimizing the Effect of Regular Updates +parent.title=Transferring Data Without Draining the Battery +parent.link=index.html + +trainingnavtop=true +previous.title=Optimizing Downloads for Efficient Network Access +previous.link=efficient-network-access.html +next.title=Redundant Downloads are Redundant +next.link=redundant_redundant.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#C2DM">Use Cloud to Device Messaging as an alternative to polling</a></li> + <li><a href="#OptimizedPolling">Optimize polling with inexact repeating alarms and exponential back-offs</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/monitoring-device-state/index.html">Optimizing Battery Life</a></li> + <li><a href="http://code.google.com/android/c2dm/">Android Cloud to Device Messaging</a></li> +</ul> + +</div> +</div> + +<p>The optimal frequency of regular updates will vary based on device state, network connectivity, user behavior, and explicit user preferences.</p> + +<p><a href="{@docRoot}training/monitoring-device-state/index.html">Optimizing Battery Life</a> discusses how to build battery-efficient apps that modify their refresh frequency based on the state of the host device. That includes disabling background service updates when you lose connectivity and reducing the rate of updates when the battery level is low.</p> + +<p>This lesson will examine how your refresh frequency can be varied to best mitigate the effect of background updates on the underlying wireless radio state machine.</p> + +<h2 id="C2DM">Use Cloud to Device Messaging as an Alternative to Polling</h2> + +<p>Every time your app polls your server to check if an update is required, you activate the wireless radio, drawing power unnecessarily, for up to 20 seconds on a typical 3G connection.</p> + +<p><a href="http://code.google.com/android/c2dm/">Android Cloud to Device Messaging (C2DM)</a> is a lightweight mechanism used to transmit data from a server to a particular app instance. Using C2DM, your server can notify your app running on a particular device that there is new data available for it.</p> + +<p>Compared to polling, where your app must regularly ping the server to query for new data, this event-driven model allows your app to create a new connection only when it knows there is data to download.</p> + +<p>The result is a reduction in unnecessary connections, and a reduced latency for updated data within your application.</p> + +<p>C2DM is implemented using a persistent TCP/IP connection. While it's possible to implement your own push service, it's best practice to use C2DM. This minimizes the number of persistent connections and allows the platform to optimize bandwidth and minimize the associated impact on battery life.</p> + +<h2 id="OptimizedPolling">Optimize Polling with Inexact Repeating Alarms and Exponential Backoffs</h2> + +<p>Where polling is required, it's good practice to set the default data refresh frequency of your app as low as possible without detracting from the user experience.</p> + +<p>A simple approach is to offer preferences to allow users to explicitly set their required update rate, allowing them to define their own balance between data freshness and battery life.</p> + +<p>When scheduling updates, use inexact repeating alarms that allow the system to "phase shift" the exact moment each alarm triggers.</p> + +<pre>int alarmType = AlarmManager.ELAPSED_REALTIME; +long interval = AlarmManager.INTERVAL_HOUR; +long start = System.currentTimeMillis() + interval; + +alarmManager.setInexactRepeating(alarmType, start, interval, pi);</pre> + +<p>If several alarms are scheduled to trigger at similar times, this phase-shifting will cause them to be triggered simultaneously, allowing each update to piggyback on top of a single active radio state change.</p> + +<p>Wherever possible, set your alarm type to {@code ELAPSED_REALTIME} or {@code RTC} rather than to their {@code _WAKEUP} equivalents. This further reduces battery impact by waiting until the phone is no longer in standby mode before the alarm triggers.</p> + +<p>You can further reduce the impact of these scheduled alarms by opportunistically reducing their frequency based on how recently your app was used.</p> + +<p>One approach is to implement an exponential back-off pattern to reduce the frequency of your updates (and / or the degree of prefetching you perform) if the app hasn't been used since the previous update. It's often useful to assert a minimum update frequency and to reset the frequency whenever the app is used, for example:</p> + +<pre>SharedPreferences sp = + context.getSharedPreferences(PREFS, Context.MODE_WORLD_READABLE); + +boolean appUsed = sp.getBoolean(PREFS_APPUSED, false); +long updateInterval = sp.getLong(PREFS_INTERVAL, DEFAULT_REFRESH_INTERVAL); + +if (!appUsed) + if ((updateInterval *= 2) > MAX_REFRESH_INTERVAL) + updateInterval = MAX_REFRESH_INTERVAL; + +Editor spEdit = sp.edit(); +spEdit.putBoolean(PREFS_APPUSED, false); +spEdit.putLong(PREFS_INTERVAL, updateInterval); +spEdit.apply(); + +rescheduleUpdates(updateInterval); +executeUpdateOrPrefetch();</pre> + +<p>You can use a similar exponential back-off pattern to reduce the effect of failed connections and download errors.</p> + +<p>The cost of initiating a network connection is the same whether you are able to contact your server and download data or not. For time-sensitive transfers where successful completion is important, an exponential back-off algorithm can be used to reduce the frequency of retries in order to minimize the associated battery impact, for example:</p> + +<pre>private void retryIn(long interval) { + boolean success = attemptTransfer(); + + if (!success) { + retryIn(interval*2 < MAX_RETRY_INTERVAL ? + interval*2 : MAX_RETRY_INTERVAL); + } +}</pre> + +<p>Alternatively, for transfers that are failure tolerant (such as regular updates), you can simply ignore failed connection and transfer attempts.</p>
\ No newline at end of file diff --git a/docs/html/training/id-auth/authenticate.jd b/docs/html/training/id-auth/authenticate.jd index 4eba87b..592fe1c 100644 --- a/docs/html/training/id-auth/authenticate.jd +++ b/docs/html/training/id-auth/authenticate.jd @@ -63,8 +63,8 @@ Tasks</code>.</li> strings that identify your app to the service. You need to obtain these strings directly from the service owner. Google has a self-service system for obtaining client ids and secrets. The article <a -href="http://code.google.com/apis/tasks/articles/oauth-and-tasks-on-android. -html">Getting Started with the Tasks API and OAuth 2.0 on Android</a> explains +href="http://code.google.com/apis/tasks/articles/oauth-and-tasks-on-android.html">Getting +Started with the Tasks API and OAuth 2.0 on Android</a> explains how to use this system to obtain these values for use with the Google Tasks API.</li> </ul> diff --git a/docs/html/training/id-auth/custom_auth.jd b/docs/html/training/id-auth/custom_auth.jd index e2bd778..0509c6e 100644 --- a/docs/html/training/id-auth/custom_auth.jd +++ b/docs/html/training/id-auth/custom_auth.jd @@ -181,6 +181,6 @@ multiple copies of it taking up space on your user's device.</p> <p>One solution is to place the service in one small, special-purpose APK. When an app wishes to use your custom account type, it can check the device to see if your custom account service is available. If not, it can direct the user to -Android Market to download the service. This may seem like a great deal of +Google Play to download the service. This may seem like a great deal of trouble at first, but compared with the alternative of re-entering credentials for every app that uses your custom account, it's refreshingly easy.</p> diff --git a/docs/html/training/implementing-navigation/ancestral.jd b/docs/html/training/implementing-navigation/ancestral.jd new file mode 100644 index 0000000..495b45d --- /dev/null +++ b/docs/html/training/implementing-navigation/ancestral.jd @@ -0,0 +1,124 @@ +page.title=Implementing Ancestral Navigation +parent.title=Implementing Effective Navigation +parent.link=index.html + +trainingnavtop=true +previous.title=Implementing Lateral Navigation +previous.link=lateral.html +next.title=Implementing Temporal Navigation +next.link=temporal.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to:</h2> +<ol> + <li><a href="#up">Implement <em>Up</em> Navigation</a></li> + <li><a href="#app-home">Properly Handle the Application Home Screen</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/design-navigation/ancestral-temporal.html">Providing Ancestral and Temporal Navigation</a></li> + <li><a href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">Tasks and Back Stack</a></li> + <li><a href="{@docRoot}design/patterns/navigation.html">Android Design: Navigation</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/EffectiveNavigation.zip" + class="button">Download the sample app</a> +<p class="filename">EffectiveNavigation.zip</p> +</div> + +</div> +</div> + + +<p><em>Ancestral navigation</em> is up the application's information hierarchy, where the top of the hierarchy (or root) is the application's home screen. This navigation concept is described in <a href="{@docRoot}training/design-navigation/ancestral-temporal.html">Designing Effective Navigation</a>. This lesson discusses how to provide ancestral navigation using the <em>Up</em> button in the action bar.</p> + + +<h2 id="up">Implement <em>Up</em> Navigation</h2> + +<p>When implementing ancestral navigation, all screens in your application that aren't the home screen should offer a means of navigating to the immediate parent screen in the hierarchy via the <em>Up</em> button in the action bar.</p> + + +<img src="{@docRoot}images/training/implementing-navigation-up.png" + alt="The Up button in the action bar." id="figure-up"> + +<p class="img-caption"><strong>Figure 1.</strong> The <em>Up</em> button in the action bar.</p> + +<p>Regardless of how the current screen was reached, pressing this button should always take the user to the same screen in the hierarchy.</p> + +<p>To implement <em>Up</em>, enable it in the action bar in your activity's {@link android.app.Activity#onCreate onCreate()} method:</p> + +<pre> +{@literal @}Override +public void onCreate(Bundle savedInstanceState) { + ... + getActionBar().setDisplayHomeAsUpEnabled(true); + ... +} +</pre> + +<p>You should also handle <code>android.R.id.home</code> in {@link android.app.Activity#onOptionsItemSelected onOptionsItemSelected()}. This resource is the menu item ID for the <em>Home</em> (or <em>Up</em>) button. To ensure that a specific parent activity is shown, <em>DO NOT</em> simply call {@link android.app.Activity#finish finish()}. Instead, use an intent such as the one described below.</p> + +<pre> +{@literal @}Override +public boolean onOptionsItemSelected(MenuItem item) { + switch (item.getItemId()) { + case android.R.id.home: + // This is called when the Home (Up) button is pressed + // in the Action Bar. + Intent parentActivityIntent = new Intent(this, MyParentActivity.class); + parentActivityIntent.addFlags( + Intent.FLAG_ACTIVITY_CLEAR_TOP | + Intent.FLAG_ACTIVITY_NEW_TASK); + startActivity(parentActivityIntent); + finish(); + return true; + } + return super.onOptionsItemSelected(item); +} +</pre> + +<p>When the current activity belongs to a task from a different application—for example if it was reached via an intent from another application—pressing <em>Up</em> should create a new task for the application with a synthesized back stack. This approach is described in <a href="{@docRoot}design/patterns/navigation.html">Android Design: Navigation</a> and the {@link android.support.v4.app.TaskStackBuilder} class reference.</p> + +<p>The {@link android.support.v4.app.NavUtils} and {@link android.support.v4.app.TaskStackBuilder} classes in the <a href="{@docRoot}sdk/compatibility-library.html">Android Support Package</a> provide helpers for implementing this behavior correctly. An example usage of these two helper classes is below:</p> + +<pre> +{@literal @}Override +public boolean onOptionsItemSelected(MenuItem item) { + switch (item.getItemId()) { + case android.R.id.home: + Intent upIntent = new Intent(this, MyParentActivity.class); + if (NavUtils.shouldUpRecreateTask(this, upIntent)) { + // This activity is not part of the application's task, so create a new task + // with a synthesized back stack. + TaskStackBuilder.from(this) + .addNextIntent(new Intent(this, MyGreatGrandParentActivity.class)) + .addNextIntent(new Intent(this, MyGrandParentActivity.class)) + .addNextIntent(upIntent) + .startActivities(); + finish(); + } else { + // This activity is part of the application's task, so simply + // navigate up to the hierarchical parent activity. + NavUtils.navigateUpTo(this, upIntent); + } + return true; + } + return super.onOptionsItemSelected(item); +} +</pre> + +<h2 id="app-home">Properly Handle the Application Home Screen</h2> + +<p>By default, the <em>Home</em> button in the action bar is interactive. Since it does not make much sense to navigate home—or up one level—while on the home screen, you should disable the button like so:</p> + +<pre> +getActionBar().setHomeButtonEnabled(false); +</pre> diff --git a/docs/html/training/implementing-navigation/descendant.jd b/docs/html/training/implementing-navigation/descendant.jd new file mode 100644 index 0000000..7d0063c --- /dev/null +++ b/docs/html/training/implementing-navigation/descendant.jd @@ -0,0 +1,65 @@ +page.title=Implementing Descendant Navigation +parent.title=Implementing Effective Navigation +parent.link=index.html + +trainingnavtop=true +previous.title=Implementing Temporal Navigation +previous.link=temporal.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to:</h2> +<ol> + <li><a href="#master-detail">Implement Master/Detail Flows Across Handsets and Tablets</a></li> + <li><a href="#external-activities">Navigate into External Activities</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/design-navigation/descendant-lateral.html">Providing Descendant and Lateral Navigation</a></li> + <li><a href="{@docRoot}design/patterns/app-structure.html">Android Design: App Structure</a></li> + <li><a href="{@docRoot}design/patterns/multi-pane-layouts.html">Android Design: Multi-pane Layouts</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/EffectiveNavigation.zip" + class="button">Download the sample app</a> +<p class="filename">EffectiveNavigation.zip</p> +</div> + +</div> +</div> + + +<p><em>Descendant navigation</em> is navigation down the application's information hierarchy. This is described in <a href="{@docRoot}training/design-navigation/descendant-lateral.html">Designing Effective Navigation</a> and also covered in <a href="{@docRoot}design/patterns/app-structure.html">Android Design: Application Structure</a>.</p> + +<p>Descendant navigation is usually implemented using {@link android.content.Intent} objects and {@link android.content.Context#startActivity startActivity()}, or by adding fragments to an activity using {@link android.app.FragmentTransaction} objects. This lesson covers other interesting cases that arise when implementing descendant navigation.</p> + +<h2 id="master-detail">Implement Master/Detail Flows Across Handsets and Tablets</h2> + +<p>In a <em>master/detail</em> navigation flow, a <em>master</em> screen contains a list of items in a collection, and a <em>detail</em> screen shows detailed information about a specific item within that collection. Implementing navigation from the master screen to the detail screen is one form of descendant navigation.</p> + +<p>Handset touchscreens are most suitable for displaying one screen at a time (either the master or the detail screen); this concern is further discussed in <a href="{@docRoot}training/design-navigation/multiple-sizes.html">Planning for Multiple Touchscreen Sizes</a>. Descendant navigation in this case is often implemented using an {@link android.content.Intent} that starts an activity representing the detail screen. On the other hand, tablet displays, especially when viewed in the landscape orientation, are best suited for showing multiple content panes at a time: the master on the left, and the detail to the right). Here, descendant navigation is usually implemented using a {@link android.app.FragmentTransaction} that adds, removes, or replaces the detail pane with new content.</p> + +<p>The basics of implementing this pattern are described in the <a href="{@docRoot}training/multiscreen/adaptui.html">Implementing Adaptive UI Flows</a> lesson of the <em>Designing for Multiple Screens</em> class. The class describes how to implement a master/detail flow using two activities on a handset and a single activity on a tablet.</p> + +<h2 id="external-activities">Navigate into External Activities</h2> + +<p>There are cases where descending into your application's information hierarchy leads to activities from other applications. For example, when viewing the contact details screen for an entry in the phone address book, a child screen detailing recent posts by the contact on a social network may belong to a social networking application.</p> + +<p>When launching another application's activity to allow the user to say, compose an email or pick a photo attachment, you generally don't want the user to return to this activity if they relaunch your application from the Launcher (the device home screen). It would be confusing if touching your application icon brought the user to a "compose email" screen.</p> + +<p>To prevent this from occurring, simply add the {@link android.content.Intent#FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET} flag to the intent used to launch the external activity, like so:</p> + +<pre> +Intent externalActivityIntent = new Intent(Intent.ACTION_PICK); +externalActivityIntent.setType("image/*"); +externalActivityIntent.addFlags( + Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET); +startActivity(externalActivityIntent); +</pre> diff --git a/docs/html/training/implementing-navigation/index.jd b/docs/html/training/implementing-navigation/index.jd new file mode 100644 index 0000000..da61c81 --- /dev/null +++ b/docs/html/training/implementing-navigation/index.jd @@ -0,0 +1,68 @@ +page.title=Implementing Effective Navigation + +trainingnavtop=true +startpage=true +next.title=Implementing Lateral Navigation +next.link=lateral.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>Dependencies and prerequisites</h2> + +<ul> + <li>API level 14</li> + <li>Understanding of fragments and Android layouts</li> + <li><a href="{@docRoot}sdk/compatibility-library.html">The Android Support Package</a></li> + <li><a href="{@docRoot}training/design-navigation/index.html">Designing Effective Navigation</a></li> +</ul> + +<h2>You should also read</h2> + +<ul> + <li><a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a></li> + <li><a href="{@docRoot}guide/topics/fundamentals/fragments.html">Fragments</a></li> + <li><a href="{@docRoot}training/multiscreen/index.html">Designing for Multiple Screens</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/EffectiveNavigation.zip" + class="button">Download the sample app</a> +<p class="filename">EffectiveNavigation.zip</p> +</div> + +</div> +</div> + + +<p>This class demonstrates how to implement the key navigation design patterns detailed in the +<a href="{@docRoot}training/design-navigation/index.html">Designing Effective Navigation</a> class. +The lessons in this class cover implementing navigation up, down, and across your application's <a +href="{@docRoot}training/design-navigation/screen-planning.html#diagram- relationships">screen +map</a>.</p> + +<p>After reading through the lessons in this class and exploring the associated sample application +(see right), you should also have a basic understanding of how to use +{@link android.app.ActionBar} and {@link android.support.v4.view.ViewPager}, two components that are fundamental to core app navigation.</p> + + +<h2 id="lessons">Lessons</h2> + + +<dl> + <dt><strong><a href="lateral.html">Implementing Lateral Navigation</a></strong></dt> + <dd>Learn how to implement tabs and horizontal paging (swipe views).</dd> + + <dt><strong><a href="ancestral.html">Implementing Ancestral Navigation</a></strong></dt> + <dd>Learn how to implement <em>Up</em> navigation.</dd> + + <dt><strong><a href="temporal.html">Implementing Temporal Navigation</a></strong></dt> + <dd>Learn how to correctly handle the <em>Back</em> button.</dd> + + <dt><strong><a href="descendant.html">Implementing Descendant Navigation</a></strong></dt> + <dd>Learn the finer points of implementing navigation into your application's information hierarchy.</dd> +</dl> diff --git a/docs/html/training/implementing-navigation/lateral.jd b/docs/html/training/implementing-navigation/lateral.jd new file mode 100644 index 0000000..d9ba5c9 --- /dev/null +++ b/docs/html/training/implementing-navigation/lateral.jd @@ -0,0 +1,252 @@ +page.title=Implementing Lateral Navigation +parent.title=Implementing Effective Navigation +parent.link=index.html + +trainingnavtop=true +next.title=Implementing Ancestral Navigation +next.link=ancestral.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#tabs">Implement Tabs</a></li> + <li><a href="#horizontal-paging">Implement Horizontal Paging (Swipe Views)</a></li> + <li><a href="#swipe-tabs">Implement Swiping Between Tabs</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/design-navigation/descendant-lateral.html">Providing Descendant and Lateral Navigation</a></li> + <li><a href="{@docRoot}design/building-blocks/tabs.html">Android Design: Tabs</a></li> + <li><a href="{@docRoot}design/patterns/swipe-views.html">Android Design: Swipe Views</a></li> +</ul> + +<h2>Try it out</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/EffectiveNavigation.zip" + class="button">Download the sample app</a> +<p class="filename">EffectiveNavigation.zip</p> +</div> + +</div> +</div> + + +<p><em>Lateral navigation</em> is navigation between sibling screens in the application's screen hierarchy (sometimes referred to as a screen map). The most prominent lateral navigation patterns are tabs and horizontal paging (also known as swipe views). This pattern and others are described in <a href="{@docRoot}training/design-navigation/descendant-lateral.html">Designing Effective Navigation</a>. This lesson covers how to implement several of the primary lateral navigation patterns in Android.</p> + +<h2 id="tabs">Implement Tabs</h2> + +<p>Tabs allow the user to navigate between sibling screens by selecting the appropriate tab indicator available at the top of the display. In Android 3.0 and later, tabs are implemented using the {@link android.app.ActionBar} class, and are generally set up in {@link android.app.Activity#onCreate Activity.onCreate()}. In some cases, such as when horizontal space is limited and/or the number of tabs is large, an appropriate alternate presentation for tabs is a dropdown list (sometimes implemented using a {@link android.widget.Spinner}).</p> + +<p>In previous versions of Android, tabs could be implemented using a {@link android.widget.TabWidget} and {@link android.widget.TabHost}. For details, see the <a href="{@docRoot}resources/tutorials/views/hello-tabwidget.html">Hello, Views</a> tutorial.</p> + +<p>As of Android 3.0, however, you should use either {@link android.app.ActionBar#NAVIGATION_MODE_TABS} or {@link android.app.ActionBar#NAVIGATION_MODE_LIST} along with the {@link android.app.ActionBar} class.</p> + +<h3>Implement the Tabs Pattern with NAVIGATION_MODE_TABS</h3> + +<p>To create tabs, you can use the following code in your activity's {@link android.app.Activity#onCreate onCreate()} method. Note that the exact presentation of tabs may vary per device and by the current device configuration, to make best use of available screen space. For example, Android may automatically collapse tabs into a dropdown list if tabs don't fit horizontally in the action bar.</p> + +<pre> +{@literal @}Override +public void onCreate(Bundle savedInstanceState) { + ... + final ActionBar actionBar = getActionBar(); + + // Specify that tabs should be displayed in the action bar. + actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_TABS); + + // Create a tab listener that is called when the user changes tabs. + ActionBar.TabListener tabListener = new ActionBar.TabListener() { + public void onTabSelected(ActionBar.Tab tab, + FragmentTransaction ft) { } + + public void onTabUnselected(ActionBar.Tab tab, + FragmentTransaction ft) { } + + public void onTabReselected(ActionBar.Tab tab, + FragmentTransaction ft) { } + }; + + // Add 3 tabs. + for (int i = 0; i < 3; i++) { + actionBar.addTab( + actionBar.newTab() + .setText("Tab " + (i + 1)) + .setTabListener(tabListener)); + } + ... +} +</pre> + +<h3>Implement the Tabs Pattern with NAVIGATION_MODE_LIST</h3> + +<p>To use a dropdown list instead, use the following code in your activity's {@link android.app.Activity#onCreate onCreate()} method. Dropdown lists are often preferable in cases where more information must be shown per navigation item, such as unread message counts, or where the number of available navigation items is large.</p> + +<pre> +{@literal @}Override +public void onCreate(Bundle savedInstanceState) { + ... + final ActionBar actionBar = getActionBar(); + + // Specify that a dropdown list should be displayed in the action bar. + actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_LIST); + + actionBar.setListNavigationCallbacks( + // Specify a SpinnerAdapter to populate the dropdown list. + new ArrayAdapter<String>( + actionBar.getThemedContext(), + android.R.layout.simple_list_item_1, + android.R.id.text1, + new String[]{ "Tab 1", "Tab 2", "Tab 3" }), + + // Provide a listener to be called when an item is selected. + new ActionBar.OnNavigationListener() { + public boolean onNavigationItemSelected( + int position, long id) { + // Take action here, e.g. switching to the + // corresponding fragment. + return true; + } + }); + ... +} +</pre> + +<h2 id="horizontal-paging">Implement Horizontal Paging (Swipe Views)</h2> + +<p>Horizontal paging, or swipe views, allow users to <a href="{@docRoot}design/patterns/swipe-views">swipe</a> horizontally on the current screen to navigate to adjacent screens. This pattern can be implemented using the {@link android.support.v4.view.ViewPager} widget, currently available as part of the <a href="{@docRoot}sdk/compatibility-library.html">Android Support Package</a>. For navigating between sibling screens representing a fixed number of sections, it's best to provide the {@link android.support.v4.view.ViewPager} with a {@link android.support.v4.app.FragmentPagerAdapter}. For horizontal paging across collections of objects, it's best to use a {@link android.support.v4.app.FragmentStatePagerAdapter}, which destroys fragments as the user navigates to other pages, minimizing memory usage.</p> + +<p>Below is an example of using a {@link android.support.v4.view.ViewPager} to swipe across a collection of objects.</p> + +<pre> +public class CollectionDemoActivity extends FragmentActivity { + // When requested, this adapter returns a DemoObjectFragment, + // representing an object in the collection. + DemoCollectionPagerAdapter mDemoCollectionPagerAdapter; + ViewPager mViewPager; + + public void onCreate(Bundle savedInstanceState) { + // ViewPager and its adapters use support library + // fragments, so use getSupportFragmentManager. + mDemoCollectionPagerAdapter = + new DemoCollectionPagerAdapter( + getSupportFragmentManager()); + mViewPager = (ViewPager) findViewById(R.id.pager); + mViewPager.setAdapter(mDemoCollectionPagerAdapter); + } +} + +// Since this is an object collection, use a FragmentStatePagerAdapter, +// and NOT a FragmentPagerAdapter. +public class DemoCollectionPagerAdapter extends + FragmentStatePagerAdapter { + public DemoCollectionPagerAdapter(FragmentManager fm) { + super(fm); + } + + {@literal @}Override + public Fragment getItem(int i) { + Fragment fragment = new DemoObjectFragment(); + Bundle args = new Bundle(); + // Our object is just an integer :-P + args.putInt(DemoObjectFragment.ARG_OBJECT, i + 1); + fragment.setArguments(args); + return fragment; + } + + {@literal @}Override + public int getCount() { + return 100; + } + + {@literal @}Override + public CharSequence getPageTitle(int position) { + return "OBJECT " + (position + 1); + } +} + +// Instances of this class are fragments representing a single +// object in our collection. +public static class DemoObjectFragment extends Fragment { + public static final String ARG_OBJECT = "object"; + + {@literal @}Override + public View onCreateView(LayoutInflater inflater, + ViewGroup container, Bundle savedInstanceState) { + // The last two arguments ensure LayoutParams are inflated + // properly. + View rootView = inflater.inflate( + R.layout.fragment_collection_object, container, false); + Bundle args = getArguments(); + ((TextView) rootView.findViewById(android.R.id.text1)).setText( + Integer.toString(args.getInt(ARG_OBJECT))); + return rootView; + } +} +</pre> + +<p>You can also add indicators to your horizontal paging UI by adding a {@link android.support.v4.view.PagerTitleStrip}. Below is an example layout XML file for an activity whose entire contents are a {@link android.support.v4.view.ViewPager} and a top-aligned {@link android.support.v4.view.PagerTitleStrip} inside it. Individual pages (provided by the adapter) occupy the remaining space inside the {@link android.support.v4.view.ViewPager}.</p> + +<pre> +<android.support.v4.view.ViewPager + xmlns:android="http://schemas.android.com/apk/res/android" + android:id="@+id/pager" + android:layout_width="match_parent" + android:layout_height="match_parent"> + + <android.support.v4.view.PagerTitleStrip + android:id="@+id/pager_title_strip" + android:layout_width="match_parent" + android:layout_height="wrap_content" + android:layout_gravity="top" + android:background="#33b5e5" + android:textColor="#fff" + android:paddingTop="4dp" + android:paddingBottom="4dp" /> + +</android.support.v4.view.ViewPager> +</pre> + +<h2 id="swipe-tabs">Implement Swiping Between Tabs</h2> + +<p>One of the key design recommendations in Android 4.0 for tabs is to <a href="{@docRoot}design/patterns/swipe-views.html">allow swiping</a> between them where appropriate. This behavior enables users to swipe horizontally across the selected tab's contents to navigate to adjacent tabs, without needed to directly interact with the tabs themselves. To implement this, you can use a {@link android.support.v4.view.ViewPager} in conjunction with the {@link android.app.ActionBar} tabs API.</p> + +<p>Upon observing the current page changing, select the corresponding tab. You can set up this behavior using an {@link android.support.v4.view.ViewPager.OnPageChangeListener} in your activity's {@link android.app.Activity#onCreate onCreate()} method:</p> + +<pre> +{@literal @}Override +public void onCreate(Bundle savedInstanceState) { + ... + mViewPager.setOnPageChangeListener( + new ViewPager.SimpleOnPageChangeListener() { + {@literal @}Override + public void onPageSelected(int position) { + // When swiping between pages, select the + // corresponding tab. + getActionBar().setSelectedNavigationItem(position); + } + }); + ... +} +</pre> + +<p>And upon selecting a tab, switch to the corresponding page in the {@link android.support.v4.view.ViewPager}. To do this, add an {@link android.app.ActionBar.TabListener} to your tab when creating it using the {@link android.app.ActionBar#newTab newTab()} method:</p> + +<pre> +actionBar.newTab() + ... + .setTabListener(new ActionBar.TabListener() { + public void onTabSelected(ActionBar.Tab tab, + FragmentTransaction ft) { + // When the tab is selected, switch to the + // corresponding page in the ViewPager. + mViewPager.setCurrentItem(tab.getPosition()); + } + ... + })); +</pre> diff --git a/docs/html/training/implementing-navigation/temporal.jd b/docs/html/training/implementing-navigation/temporal.jd new file mode 100644 index 0000000..f36991f --- /dev/null +++ b/docs/html/training/implementing-navigation/temporal.jd @@ -0,0 +1,83 @@ +page.title=Implementing Temporal Navigation +parent.title=Implementing Effective Navigation +parent.link=index.html + +trainingnavtop=true +previous.title=Implementing Ancestral Navigation +previous.link=ancestral.html +next.title=Implementing Descendant Navigation +next.link=descendant.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to:</h2> +<ol> + <li><a href="#back-fragments">Implement <em>Back</em> Navigation with Fragments</a></li> + <li><a href="#back-webviews">Implement <em>Back</em> Navigation with WebViews</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/design-navigation/ancestral-temporal.html">Providing Ancestral and Temporal Navigation</a></li> + <li><a href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">Tasks and Back Stack</a></li> + <li><a href="{@docRoot}design/patterns/navigation.html">Android Design: Navigation</a></li> +</ul> + +</div> +</div> + + +<p><em>Temporal navigation</em> is navigation to previously visited screens. Users can visit previous screens by pressing the device <em>Back</em> button. This user interface pattern is described further in <a href="{@docRoot}training/design-navigation/ancestral-temporal.html">Providing Ancestral and Temporal Navigation</a> in <em>Designing Effective Navigation</em> and in <a href="{@docRoot}design/patterns/navigation.html">Android Design: Navigation</a>.</p> + +<p>Android handles basic <em>Back</em> navigation for you (see <a href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">Tasks and Back Stack</a> for details on this behavior). This lesson discusses a number of cases where applications should provide specialized logic for the <em>Back</em> button.</p> + + +<h2 id="back-fragments">Implement <em>Back</em> Navigation with Fragments</h2> + +<p>When using fragments in your application, individual {@link android.app.FragmentTransaction} objects can represent context changes that should be added to the back stack. For example, if you are implementing a <a href="descendant.html#master-detail">master/detail flow</a> on a handset by swapping out fragments (thus emulating a {@link android.app.Activity#startActivity startActivity()} call), you should ensure that pressing the <em>Back</em> button on a detail screen returns the user to the master screen. To do so, you can use {@link android.app.FragmentTransaction#addToBackStack addToBackStack()}:</p> + +<pre> +// Works with either the framework FragmentManager or the +// support package FragmentManager (getSupportFragmentManager). +getFragmentManager().beginTransaction() + .add(detailFragment, "detail") + + // Add this transaction to the back stack and commit. + .addToBackStack() + .commit(); +</pre> + +<p>The activity's {@link android.app.FragmentManager} handles <em>Back</em> button presses if there are {@link android.app.FragmentTransaction} objects on the back stack. When this happens, the {@link android.app.FragmentManager} pops the most recent transaction off the back stack and performs the reverse action (e.g., removing a fragment if the transaction added it).</p> + +<p>If your application updates other user interface elements to reflect the current state of your fragments, such as the action bar, remember to update the UI when you commit the transaction. You should update your user interface after the fragment manager back stack changes in addition to when you commit the transaction. You can listen for when a <code>FragmentTransaction</code> is reverted by setting up an {@link android.app.FragmentManager.OnBackStackChangedListener}:</p> + +<pre> +getFragmentManager().addOnBackStackChangedListener( + new FragmentManager.OnBackStackChangedListener() { + public void onBackStackChanged() { + // Update your UI here. + } + }); +</pre> + +<h2 id="back-webviews">Implement <em>Back</em> Navigation with WebViews</h2> + +<p>If a part of your application is contained in a {@link android.webkit.WebView}, it may be appropriate for <em>Back</em> to traverse browser history. To do so, you can override {@link android.app.Activity#onBackPressed onBackPressed()} and proxy to the <code>WebView</code> if it has history state:</p> + +<pre> +{@literal @}Override +public void onBackPressed() { + if (mWebView.canGoBack()) { + mWebView.goBack(); + return; + } + + // Otherwise defer to system default behavior. + super.onBackPressed(); +} +</pre> + +<p>Be careful when using this mechanism with highly dynamic web pages that can grow a large history. Pages that generate an extensive history, such as those that make frequent changes to the document hash, may make it tedious for users to get out of your activity.</p> diff --git a/docs/html/training/improving-layouts/optimizing-layout.jd b/docs/html/training/improving-layouts/optimizing-layout.jd index 65c8af7..0eaf199 100644 --- a/docs/html/training/improving-layouts/optimizing-layout.jd +++ b/docs/html/training/improving-layouts/optimizing-layout.jd @@ -18,7 +18,7 @@ next.link=reusing-layouts.html <ol> <li><a href="#Inspect">Inspect Your Layout</a></li> <li><a href="#Revise">Revise Your Layout</a></li> - <li><a href="#Layoutopt">Use Layoutopt</a></li> + <li><a href="#Lint">Use Lint</a></li> </ol> <!-- other docs (NOT javadocs) --> @@ -44,7 +44,7 @@ is inflated repeatedly, such as when used in a {@link android.widget.ListView} o android.widget.GridView}.</p> <p>In this lesson you'll learn to use <a -href="{@docRoot}guide/developing/tools/hierarchy-viewer.html">Heirachy Viewer</a> and <a +href="{@docRoot}guide/developing/tools/hierarchy-viewer.html">Hierarchy Viewer</a> and <a href="{@docRoot}guide/developing/tools/layoutopt.html">Layoutopt</a> to examine and optimize your layout.</p> @@ -53,7 +53,7 @@ layout.</p> <h2 id="Inspect">Inspect Your Layout</h2> <p>The Android SDK tools include a tool called <a -href="{@docRoot}guide/developing/tools/hierarchy-viewer.html">Heirachy Viewer</a> that allows +href="{@docRoot}guide/developing/tools/hierarchy-viewer.html">Hierarchy Viewer</a> that allows you to analyze your layout while your application is running. Using this tool helps you discover bottlenecks in the layout performance.</p> @@ -130,27 +130,28 @@ example of how each layout has appropriate uses and you should carefully conside layout weight is necessary.</p> -<h2 id="Layoutopt">Use Layoutopt</h2> +<h2 id="Lint">Use Lint</h2> + +<p>It is always good practice to run the <a href="http://tools.android.com/tips/lint">Lint</a> tool on your layout files to search for possible view hierarchy optimizations. Lint has replaced the Layoutopt tool and has much greater functionality. Some examples of Lint <a +href="http://tools.android.com/tips/lint-checks">rules</a> are:</p> + +<ul> +<li>Use compound drawables - A {@link android.widget.LinearLayout} which contains an {@link android.widget.ImageView} and a {@link android.widget.TextView} can be more efficiently handled as a compound drawable.</li> +<li>Merge root frame - If a {@link android.widget.FrameLayout} is the root of a layout and does not provide background or padding etc, it can be replaced with a merge tag which is slightly more efficient.</li> +<li>Useless leaf - A layout that has no children or no background can often be removed (since it is invisible) for a flatter and more efficient layout hierarchy.</li> +<li>Useless parent - A layout with children that has no siblings, is not a {@link android.widget.ScrollView} or a root layout, and does not have a background, can be removed and have its children moved directly into the parent for a flatter and more efficient layout hierarchy.</li> +<li>Deep layouts - Layouts with too much nesting are bad for performance. Consider using flatter layouts such as {@link android.widget.RelativeLayout} or {@link android.widget.GridLayout} to improve performance. The default maximum depth is 10.</li> +</ul> + +<p>Another benefit of Lint is that it is integrated into the Android Development Tools for Eclipse (ADT 16+). Lint automatically runs whenever you export an APK, edit and save an XML file or use the Layout Editor. To manually force Lint to run press the Lint button in the Eclipse toolbar.</p> + +<img src="{@docRoot}images/training/lint_icon.png" alt="" /> + +<p>When used inside Eclipse, Lint has the ability to automatically fix some issues, provide suggestions for others and jump directly to the offending code for review. If you don’t use Eclipse for your development, Lint can also be run from the command line. More information about Lint is available at <a href="http://tools.android.com/tips/lint">tools.android.com</a>.</p> + + -<p>It is always good practice to also run the <a -href="{@docRoot}guide/developing/tools/layoutopt.html">layoutopt</a> tool on your final layout files -to search for places in your view hierarchy that may be optimized. Layoutopt is also in your SDK -{@code tools/} directory and takes a layout directory name or a space-separated list of layout files -that you'd like to inspect.</p> -<p>When you run {@code layoutopt} on a layout file, it prints a line number for each issue found, a -description of the issue, and for some types of issues it also suggests a resolution. For -example:</p> -<pre class="no-pretty-print classic"> -$ layoutopt samples/ -samples/compound.xml - 7:23 The root-level <FrameLayout/> can be replaced with <merge/> - 11:21 This LinearLayout layout or its FrameLayout parent is useless -samples/simple.xml - 7:7 The root-level <FrameLayout/> can be replaced with <merge/> -</pre> -<p>After you apply the suggested layout optimizations, run Hierarchy Viewer again to inspect the -performance changes.</p> diff --git a/docs/html/training/monitoring-device-state/docking-monitoring.jd b/docs/html/training/monitoring-device-state/docking-monitoring.jd index 392ce30..82d655e 100644 --- a/docs/html/training/monitoring-device-state/docking-monitoring.jd +++ b/docs/html/training/monitoring-device-state/docking-monitoring.jd @@ -15,7 +15,7 @@ next.link=connectivity-monitoring.html <h2>This lesson teaches you to</h2> <ol> - <li><a href="#CurrentDockState">Request the Audio Focus</a></li> + <li><a href="#CurrentDockState">Determine the Current Docking State</a></li> <li><a href="#DockType">Determine the Current Dock Type</a></li> <li><a href="#MonitorDockState">Monitor for Changes in the Dock State or Type</a></li> </ol> diff --git a/docs/html/training/monitoring-device-state/manifest-receivers.jd b/docs/html/training/monitoring-device-state/manifest-receivers.jd index 556a733..0b79ce6 100644 --- a/docs/html/training/monitoring-device-state/manifest-receivers.jd +++ b/docs/html/training/monitoring-device-state/manifest-receivers.jd @@ -14,7 +14,7 @@ previous.link=connectivity-monitoring.html <h2>This lesson teaches you to</h2> <ol> - <li><a href="ToggleReceivers">Toggle and Cascade State Change Receivers to Improve + <li><a href="#ToggleReceivers">Toggle and Cascade State Change Receivers to Improve Efficiency</a></li> </ol> diff --git a/docs/html/training/multiple-apks/api.jd b/docs/html/training/multiple-apks/api.jd index d8588d4..3492245 100644 --- a/docs/html/training/multiple-apks/api.jd +++ b/docs/html/training/multiple-apks/api.jd @@ -44,7 +44,7 @@ How to have your (Cup)cake and eat it too</a></li> </div> -<p>When developing your Android application to take advantage of multiple APKs on Android Market, +<p>When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each covering a slightly different range of API levels. You will also gain some tools @@ -198,7 +198,7 @@ initialization procedures that don’t change much from APK to APK.</p> <h2 id="AdjustManifests">Adjust the Manifests</h2> -<p>When a user downloads an application which uses multiple APKs through Android Market, the correct +<p>When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using two simple rules:</p> <ul> <li>The manifest has to show that particular APK is eligible</li> @@ -278,19 +278,20 @@ green ≥ blue. Therefore we can effectively collapse the chart to look lik </table> <p> -Now, let’s further assume that the Red APK has some requirement on it that the other two don’t. The -Market Filters page of the Android Developer guide has a whole list of possible culprits. For the +Now, let’s further assume that the Red APK has some requirement on it that the other two don’t. +<a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> page of +the Android Developer guide has a whole list of possible culprits. For the sake of example, let’s assume that red requires a front-facing camera. In fact, the entire point of the red APK is to combine the front-facing camera with sweet new functionality that was added in API 11. But, it turns out, not all devices that support API 11 even HAVE front-facing cameras! The horror!</p> -<p>Fortunately, if a user is browsing Market from one such device, Android Market will look at the +<p>Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having determined that Red and that device are not a match made in digital heaven. It will then see that Green is not only forward-compatible with devices with API 11 (since no maxSdkVersion was defined), but also doesn’t care whether or not there’s a front-facing camera! The app can still be downloaded -from Android Market by the user, because despite the whole front-camera mishap, there was still an +from Google Play by the user, because despite the whole front-camera mishap, there was still an APK that supported that particular API level.</p> <p> In order to keep all your APKs on separate "tracks", it’s important to have a good version code @@ -330,7 +331,7 @@ Red:11001, 11002, 11003, 11004...</p> </pre> <h2 id="PreLaunch">Go Over Pre-launch Checklist</h2> -<p> Before uploading to Android Market, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all applications being uploaded to Android Market.</p> +<p> Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all applications being uploaded to Google Play.</p> <ul> <li>All APKs must have the same package name</li> @@ -342,7 +343,7 @@ Red:11001, 11002, 11003, 11004...</p> </ul> <p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them. </p> @@ -370,10 +371,14 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK won’t be visible to very many devices.</p> -<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since API 11 is Honeycomb (the version of Android optimized specifically for tablets), and no Honeycomb devices have telephony hardware in them, Market will filter out this APK in all cases, until future devices come along which are higher in API level AND possess telephony hardware. +<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since API 11 is Honeycomb (the version of Android optimized specifically for tablets), and no Honeycomb devices have telephony hardware in them, Google Play will filter out this APK in all cases, until future devices come along which are higher in API level AND possess telephony hardware. </p> <p>Fortunately this is easily fixed by adding the following to your manifest:</p> <pre> <uses-feature android:name="android.hardware.telephony" android:required="false" /> </pre> -<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have, to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> +<p>The <code>android.hardware.touchscreen</code> requirement is also implicitly added. If you want your APK to be visible on TVs which are non-touchscreen devices you should add the following to your manifest:</p> +<pre> +<uses-feature android:name="android.hardware.touchscreen" android:required="false" /> +</pre> +<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have, to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> diff --git a/docs/html/training/multiple-apks/index.jd b/docs/html/training/multiple-apks/index.jd index f9b2b43..d92c106 100644 --- a/docs/html/training/multiple-apks/index.jd +++ b/docs/html/training/multiple-apks/index.jd @@ -16,7 +16,7 @@ next.link=api.html <ul> <li>Android 1.0 and higher</li> - <li>You must have an <a href="http://market.android.com/publish">Android Market</a> publisher + <li>You must have an <a href="http://play.google.com/apps/publish">Google Play</a> publisher account</li> </ul> @@ -30,7 +30,7 @@ Support</a></li> </div> </div> -<p>Multiple APK support is a feature in Android Market that allows you to publish multiple APKs +<p>Multiple APK support is a feature of Google Play that allows you to publish multiple APKs under the same application listing. Each APK is a complete instance of your application, optimized to target specific device configurations. Each APK can target a specific set of GL textures, API levels, screen sizes, or some combination thereof.</p> @@ -39,7 +39,7 @@ textures, API levels, screen sizes, or some combination thereof.</p> configuration variables. Each lesson covers basics about how to organize your codebase and target the right devices, as well as the smart way to avoid pitfalls such as unnecessary redundancy across your codebase, and making mistakes in your manifest that could render an APK invisible to all -devices in Android Market. By going through any of these lessons, you'll know how to develop +devices on Google Play. By going through any of these lessons, you'll know how to develop multiple APKs the smart way, make sure they're targeting the devices you want them to, and know how to catch mistakes <em>before</em> your app goes live.</p> diff --git a/docs/html/training/multiple-apks/multiple.jd b/docs/html/training/multiple-apks/multiple.jd index 26a3a93..b30068f 100644 --- a/docs/html/training/multiple-apks/multiple.jd +++ b/docs/html/training/multiple-apks/multiple.jd @@ -40,7 +40,7 @@ Support</a></li> </div> </div> -<p>When developing your Android application to take advantage of multiple APKs on Android Market, +<p>When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each covering a different class of screen size. You will also gain some tools necessary to @@ -227,7 +227,7 @@ initialization procedures that don’t change much from APK to APK.</p> <h2 id="AdjustManifests">Adjust the Manifests</h2> -<p>When a user downloads an application which uses multiple APKs through Android Market, the correct +<p>When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using two simple rules: <ul> @@ -329,17 +329,17 @@ preference as follows:</p> Purple ≥ Red ≥ Green ≥ Blue </p><p> Why allow all the overlap? Let’s pretend that the Purple APK has some requirement on it that the -other two don’t. The <a href="{@docRoot}guide/appendix/market-filters.html">Market Filters page</a> +other two don’t. The <a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> page of the Android Developer guide has a whole list of possible culprits. For the sake of example, let’s assume that Purple requires a front-facing camera. In fact, the entire point of Purple is to use entertaining things with the front-facing camera! But, it turns out, not all API 11+ devices even HAVE front-facing cameras! The horror!</p> -<p>Fortunately, if a user is browsing Market from one such device, Android Market will look at the +<p>Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the manifest, see that Purple lists the front-facing camera as a requirement, and quietly ignore it, having determined that Purple and that device are not a match made in digital heaven. It will then see that Red is not only compatible with xlarge devices, but also doesn’t care whether or not -there’s a front-facing camera! The app can still be downloaded from Android Market by the user, +there’s a front-facing camera! The app can still be downloaded from Google Play by the user, because despite the whole front-camera mishap, there was still an APK that supported that particular API level.</p> @@ -420,9 +420,9 @@ automatically set to false, since that size didn’t exist yet. So be explicit! </p> <h2 id="PreLaunch">Go Over Pre-launch Checklist</h2> -<p> Before uploading to Android Market, double-check the following items. Remember that these are +<p> Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all -applications being uploaded to Android Market.</p> +applications being uploaded to Google Play.</p> <ul> <li>All APKs must have the same package name.</li> <li>All APKs must be signed with the same certificate.</li> @@ -439,7 +439,7 @@ customizable device emulators in the business sitting on your development machin </ul> <p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them. </p> @@ -467,11 +467,15 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK will be invisible to most, if not all devices.</p> -<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. +<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. </p> <p>Fortunately this is easily fixed by adding the following to your manifest:<p> <pre> <uses-feature android:name="android.hardware.telephony" android:required="false" /> </pre> +<p>The <code>android.hardware.touchscreen</code> requirement is also implicitly added. If you want your APK to be visible on TVs which are non-touchscreen devices you should add the following to your manifest:</p> +<pre> +<uses-feature android:name="android.hardware.touchscreen" android:required="false" /> +</pre> -<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> +<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> diff --git a/docs/html/training/multiple-apks/screensize.jd b/docs/html/training/multiple-apks/screensize.jd index 0ed972a..ac679a7 100644 --- a/docs/html/training/multiple-apks/screensize.jd +++ b/docs/html/training/multiple-apks/screensize.jd @@ -43,7 +43,7 @@ Support</a></li> </div> -<p>When developing your Android application to take advantage of multiple APKs on Android Market, +<p>When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each covering a different class of screen size. You will also gain some tools necessary to @@ -178,7 +178,7 @@ initialization procedures that don’t change much from APK to APK.</p> <h2 id="AdjustManifests">Adjust the Manifests</h2> -<p>When a user downloads an application which uses multiple APKs through Android Market, the correct +<p>When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using two simple rules:</p> <ul> <li>The manifest has to show that particular APK is eligible</li> @@ -227,17 +227,17 @@ each APK such that red ≥ green ≥ blue, the chart effectively collaps </table> <p> Now, let’s further assume that the Red APK has some requirement on it that the other two don’t. The -<a href="{@docRoot}guide/appendix/market-filters.html">Market Filters page</a> of the Android +<a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> page of the Android Developer guide has a whole list of possible culprits. For the sake of example, let’s assume that red requires a front-facing camera. In fact, the entire point of the red APK is to use the extra available screen space to do entertaining things with that front-facing camera. But, it turns out, not all xlarge devices even HAVE front-facing cameras! The horror!</p> -<p>Fortunately, if a user is browsing Market from one such device, Android Market will look at the +<p>Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having determined that Red and that device are not a match made in digital heaven. It will then see that Green is not only compatible with xlarge devices, but also doesn’t care whether or not there’s a -front-facing camera! The app can still be downloaded from Android Market by the user, because +front-facing camera! The app can still be downloaded from Google Play by the user, because despite the whole front-camera mishap, there was still an APK that supported that particular screen size.</p> @@ -300,9 +300,9 @@ So be explicit! </p> <h2 id="PreLaunch">Go Over Pre-launch Checklist</h2> -<p> Before uploading to Android Market, double-check the following items. Remember that these are +<p> Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all -applications being uploaded to Android Market.</p> +applications being uploaded to Google Play.</p> <ul> <li>All APKs must have the same package name</li> <li>All APKs must be signed with the same certificate</li> @@ -317,7 +317,7 @@ customizable device emulators in the business sitting on your development machin </ul> <p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them. </p> @@ -345,11 +345,16 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK will be invisible to most, if not all devices.</p> -<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. +<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. </p> <p>Fortunately this is easily fixed by adding the following to your manifest:</p> <pre> <uses-feature android:name="android.hardware.telephony" android:required="false" /> </pre> -<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> +<p>The <code>android.hardware.touchscreen</code> requirement is also implicitly added. If you want your APK to be visible on TVs which are non-touchscreen devices you should add the following to your manifest:</p> +<pre> +<uses-feature android:name="android.hardware.touchscreen" android:required="false" /> +</pre> + +<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> diff --git a/docs/html/training/multiple-apks/texture.jd b/docs/html/training/multiple-apks/texture.jd index 2bbe511..497d6b8 100644 --- a/docs/html/training/multiple-apks/texture.jd +++ b/docs/html/training/multiple-apks/texture.jd @@ -40,7 +40,7 @@ Support</a></li> </div> </div> -<p>When developing your Android application to take advantage of multiple APKs on Android Market, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each supporting a different subset of OpenGL texture formats. You will also gain some tools necessary to make maintaining a multiple APK codebase as painless as possible.</p> +<p>When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each supporting a different subset of OpenGL texture formats. You will also gain some tools necessary to make maintaining a multiple APK codebase as painless as possible.</p> <h2 id="Confirm">Confirm You Need Multiple APKs</h2> @@ -158,7 +158,7 @@ initialization procedures that don’t change much from APK to APK.</p> <h2 id="AdjustManifests">Adjust the Manifests</h2> -<p>When a user downloads an application which uses multiple APKs through Android Market, the correct +<p>When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using some simple rules:</p> <ul> @@ -246,9 +246,9 @@ following:</p> </pre> <h2 id="PreLaunch">Go Over Pre-launch Checklist</h2> -<p>Before uploading to Android Market, double-check the following items. Remember that these are +<p>Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all -applications being uploaded to Android Market.</p> +applications being uploaded to Google Play.</p> <ul> <li>All APKs must have the same package name</li> @@ -262,7 +262,7 @@ customizable device emulators in the business sitting on your development machin </ul> <p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them. </p> @@ -290,10 +290,15 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK will be invisible to most, if not all devices.</p> -<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. +<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. </p> <p>Fortunately this is easily fixed by adding the following to your manifest:</p> <pre> <uses-feature android:name="android.hardware.telephony" android:required="false" /> </pre> -<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> +<p>The <code>android.hardware.touchscreen</code> requirement is also implicitly added. If you want your APK to be visible on TVs which are non-touchscreen devices you should add the following to your manifest:</p> +<pre> +<uses-feature android:name="android.hardware.touchscreen" android:required="false" /> +</pre> + +<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> diff --git a/docs/html/training/multiscreen/screensizes.jd b/docs/html/training/multiscreen/screensizes.jd index 2db0b67..bf19b08 100644 --- a/docs/html/training/multiscreen/screensizes.jd +++ b/docs/html/training/multiscreen/screensizes.jd @@ -164,14 +164,14 @@ to implement these layouts, you could have the following files:</p> {@sample development/samples/training/multiscreen/newsreader/res/layout/onepane.xml all} </li> - <li><code>res/layout-xlarge/main.xml</code>, two-pane layout: + <li><code>res/layout-large/main.xml</code>, two-pane layout: {@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes.xml all} </li> </ul> -<p>Notice the <code>xlarge</code> qualifier in the directory name of the second layout. This layout -will be selected on devices with screens classified as extra-large (for example, 10" tablets). The +<p>Notice the <code>large</code> qualifier in the directory name of the second layout. This layout +will be selected on devices with screens classified as large (for example, 7" tablets and above). The other layout (without qualifiers) will be selected for smaller devices.</p> @@ -188,7 +188,7 @@ though they are all considered to be "large" screens. That's why Android introdu width given in dp. For example, the typical 7" tablet has a minimum width of 600 dp, so if you want your UI to have two panes on those screens (but a single list on smaller screens), you can use the same two layouts from the previous section for single -and two-pane layouts, but instead of the <code>xlarge</code> size qualifier, use +and two-pane layouts, but instead of the <code>large</code> size qualifier, use <code>sw600dp</code> to indicate the two-pane layout is for screens on which the smallest-width is 600 dp:</p> @@ -209,9 +209,9 @@ while smaller screens will select the <code>layout/main.xml</code> (single-pane) layout.</p> <p>However, this won't work well on pre-3.2 devices, because they don't -recognize <code>sw600dp</code> as a size qualifier, so you still have to use the <code>xlarge</code> +recognize <code>sw600dp</code> as a size qualifier, so you still have to use the <code>large</code> qualifier as well. So, you should have a file named -<code>res/layout-xlarge/main.xml</code> +<code>res/layout-large/main.xml</code> which is identical to <code>res/layout-sw600dp/main.xml</code>. In the next section you'll see a technique that allows you to avoid duplicating the layout files this way.</p> @@ -222,20 +222,20 @@ you'll see a technique that allows you to avoid duplicating the layout files thi Therefore, you should also still use the abstract size bins (small, normal, large and xlarge) to be compatible with earlier versions. For example, if you want to design your UI so that it shows a single-pane UI on phones but a -multi-pane UI on 7" tablets and larger devices, you'd have to supply these +multi-pane UI on 7" tablets, TVs and other large devices, you'd have to supply these files:</p> <p><ul> <li><code>res/layout/main.xml:</code> single-pane layout</li> -<li><code>res/layout-xlarge:</code> multi-pane layout</li> +<li><code>res/layout-large:</code> multi-pane layout</li> <li><code>res/layout-sw600dp:</code> multi-pane layout</li> </ul></p> <p>The last two files are identical, because one of them will be matched by -Android 3.2 devices, and the other one is for the benefit of tablets with +Android 3.2 devices, and the other one is for the benefit of tablets and TVs with earlier versions of Android.</p> -<p>To avoid this duplication of the same file for tablets (and the maintenance +<p>To avoid this duplication of the same file for tablets and TVs (and the maintenance headache resulting from it), you can use alias files. For example, you can define the following layouts:</p> @@ -247,7 +247,7 @@ layouts:</p> <p>And add these two files:</p> <p><ul> -<li><code>res/values-xlarge/layout.xml</code>: +<li><code>res/values-large/layout.xml</code>: <pre> <resources> <item name="main" type="layout">@layout/main_twopanes</item> @@ -267,9 +267,9 @@ layouts:</p> <p>These latter two files have identical content, but they don’t actually define the layout. They merely set up {@code main} to be an alias to {@code main_twopanes}. Since -these files have <code>xlarge</code> and <code>sw600dp</code> selectors, they are -applied to tablets regardless of Android version (pre-3.2 tablets match -{@code xlarge}, and post-3.2 will match <code>sw600dp</code>).</p> +these files have <code>large</code> and <code>sw600dp</code> selectors, they are +applied to tablets and TVs regardless of Android version (pre-3.2 tablets and TVs match +{@code large}, and post-3.2 will match <code>sw600dp</code>).</p> <h2 id="TaskUseOriQuali">Use Orientation Qualifiers</h2> @@ -285,6 +285,7 @@ behaves in each screen size and orientation:</p> <li><b>7" tablet, landscape:</b> dual pane, wide, with action bar</li> <li><b>10" tablet, portrait:</b> dual pane, narrow, with action bar</li> <li><b>10" tablet, landscape:</b> dual pane, wide, with action bar</li> +<li><b>TV, landscape:</b> dual pane, wide, with action bar</li> </ul></p> <p>So each of these layouts is defined in an XML file in the @@ -319,11 +320,11 @@ all} {@sample development/samples/training/multiscreen/newsreader/res/values-sw600dp-port/layouts.xml all} -<p><code>res/values-xlarge-land/layouts.xml</code>:</p> -{@sample development/samples/training/multiscreen/newsreader/res/values-xlarge-land/layouts.xml all} +<p><code>res/values-large-land/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-large-land/layouts.xml all} -<p><code>res/values-xlarge-port/layouts.xml</code>:</p> -{@sample development/samples/training/multiscreen/newsreader/res/values-xlarge-port/layouts.xml all} +<p><code>res/values-large-port/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-large-port/layouts.xml all} diff --git a/docs/html/training/search/backward-compat.jd b/docs/html/training/search/backward-compat.jd new file mode 100644 index 0000000..0894fa9 --- /dev/null +++ b/docs/html/training/search/backward-compat.jd @@ -0,0 +1,87 @@ +page.title=Remaining Backward Compatible +trainingnavtop=true +previous.title=Storing and Searching for Data +previous.link=search.html + +@jd:body + + <div id="tb-wrapper"> + <div id="tb"> + <h2>This lesson teaches you to</h2> + + <ul> + <li><a href="{@docRoot}training/search/backward-compat.html#set-sdk">Set Minimum + and Target API levels</a></li> + + <li><a href="{@docRoot}training/search/backward-compat.html#provide-sd">Provide the Search + Dialog for Older Devices</a></li> + + <li><a href="{@docRoot}training/search/backward-compat.html#check-ver">Check the Android Build + Version at Runtime</a></li> + </ul> + </div> + </div> + + <p>The {@link android.widget.SearchView} and action bar are only available on Android 3.0 and + later. To support older platforms, you can fall back to the search dialog. The search dialog is a + system provided UI that overlays on top of your application when invoked.</p> + + <h2 id="set-sdk">Set Minimum and Target API levels</h2> + + <p>To setup the search dialog, first declare in your manifest that you want to support older + devices, but want to target Android 3.0 or later versions. When you do this, your application + automatically uses the action bar on Android 3.0 or later and uses the traditional menu system on + older devices:</p> + <pre> +<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="15" /> + +<application> +... +</pre> + + <h2 id="provide-sd">Provide the Search Dialog for Older Devices</h2> + + <p>To invoke the search dialog on older devices, call {@link + android.app.Activity#onSearchRequested onSearchRequested()} whenever a user selects the search + menu item from the options menu. Because Android 3.0 and higher devices show the + {@link android.widget.SearchView} in the action bar (as demonstrated in the first lesson), only versions + older than 3.0 call {@link android.app.Activity#onOptionsItemSelected onOptionsItemSelected()} when the + user selects the search menu item. + </p> + <pre> +@Override +public boolean onOptionsItemSelected(MenuItem item) { + switch (item.getItemId()) { + case R.id.search: + onSearchRequested(); + return true; + default: + return false; + } +} +</pre> + + <h2 id="check-ver">Check the Android Build Version at Runtime</h2> + + <p>At runtime, check the device version to make sure an unsupported use of {@link + android.widget.SearchView} does not occur on older devices. In our example code, this happens in + the {@link android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()} method:</p> + <pre> +@Override +public boolean onCreateOptionsMenu(Menu menu) { + + MenuInflater inflater = getMenuInflater(); + inflater.inflate(R.menu.options_menu, menu); + + if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { + SearchManager searchManager = + (SearchManager) getSystemService(Context.SEARCH_SERVICE); + SearchView searchView = + (SearchView) menu.findItem(R.id.search).getActionView(); + searchView.setSearchableInfo( + searchManager.getSearchableInfo(getComponentName())); + searchView.setIconifiedByDefault(false); + } + return true; +} +</pre> diff --git a/docs/html/training/search/index.jd b/docs/html/training/search/index.jd new file mode 100644 index 0000000..bfd1618 --- /dev/null +++ b/docs/html/training/search/index.jd @@ -0,0 +1,53 @@ +page.title=Adding Search Functionality +trainingnavtop=true +startpage=true +next.title=Setting Up the Search Interface +next.link=setup.html + +@jd:body + + <div id="tb-wrapper"> + <div id="tb"> + <h2>Dependencies and prerequisites</h2> + + <ul> + <li>Android 3.0 or later (with some support for Android 2.1)</li> + + <li>Experience building an Android <a href="{@docRoot}guide/topics/ui/index.html">User + Interface</a></li> + </ul> + + <h2>You should also read</h2> + + <ul> + <li><a href="{@docRoot}guide/topics/search/index.html">Search</a></li> + + <li><a href="{@docRoot}resources/samples/SearchableDictionary/index.html">Searchable + Dictionary Sample App</a></li> + </ul> + </div> + </div> + + <p>Android's built-in search features offer apps an easy way to provide a + consistent search experience for all users. There are two ways to implement search in your app + depending on the version of Android that is running on the device. This class covers how to add + search with {@link android.widget.SearchView}, which was introduced in Android 3.0, while + maintaining backward compatibility with older versions of Android by using the default search + dialog provided by the system.</p> + + <h2>Lessons</h2> + + <dl> + <dt><b><a href="setup.html">Setting Up the Search Interface</a></b></dt> + + <dd>Learn how to add a search interface to your app and how to configure an activity to handle + search queries.</dd> + + <dt><b><a href="search.html">Storing and Searching for Data</a></b></dt> + + <dd>Learn a simple way to store and search for data in a SQLite virtual database table.</dd> + + <dt><b><a href="backward-compat.html">Remaining Backward Compatible</a></b></dt> + + <dd>Learn how to keep search features backward compatible with older devices by using.</dd> + </dl>
\ No newline at end of file diff --git a/docs/html/training/search/search.jd b/docs/html/training/search/search.jd new file mode 100644 index 0000000..17e7640 --- /dev/null +++ b/docs/html/training/search/search.jd @@ -0,0 +1,217 @@ +page.title=Storing and Searching for Data +trainingnavtop=true +previous.title=Setting Up the Search Interface +previous.link=setup.html +next.title=Remaining Backward Compatible +next.link=backward-compat.html + +@jd:body + + <div id="tb-wrapper"> + <div id="tb"> + <h2>This lesson teaches you to</h2> + + <ul> + <li><a href="{@docRoot}training/search/search.html#create">Create the Virtual + Table</a></li> + + <li><a href="{@docRoot}training/search/search.html#populate">Populate the Virtual + Table</a></li> + + <li><a href="{@docRoot}training/search/search.html#search">Search for the Query</a></li> + </ul> + </div> + </div> + + <p>There are many ways to store your data, such as in an online database, in a local SQLite + database, or even in a text file. It is up to you to decide what is the best solution for your + application. This lesson shows you how to create a SQLite virtual table that can provide robust + full-text searching. The table is populated with data from a text file that contains a word and + definition pair on each line in the file.</p> + + <h2 id="create">Create the Virtual Table</h2> + + <p>A virtual table behaves similarly to a SQLite table, but reads and writes to an object in + memory via callbacks, instead of to a database file. To create a virtual table, create a class + for the table:</p> + <pre> +public class DatabaseTable { + private final DatabaseOpenHelper mDatabaseOpenHelper; + + public DatabaseTable(Context context) { + mDatabaseOpenHelper = new DatabaseOpenHelper(context); + } +} +</pre> + + <p>Create an inner class in <code>DatabaseTable</code> that extends {@link + android.database.sqlite.SQLiteOpenHelper}. The {@link android.database.sqlite.SQLiteOpenHelper} class + defines abstract methods that you must override so that your database table can be created and + upgraded when necessary. For example, here is some code that declares a database table that will + contain words for a dictionary app:</p> + <pre> +public class DatabaseTable { + + private static final String TAG = "DictionaryDatabase"; + + //The columns we'll include in the dictionary table + public static final String COL_WORD = "WORD"; + public static final String COL_DEFINITION = "DEFINITION"; + + private static final String DATABASE_NAME = "DICTIONARY"; + private static final String FTS_VIRTUAL_TABLE = "FTS"; + private static final int DATABASE_VERSION = 1; + + private final DatabaseOpenHelper mDatabaseOpenHelper; + + public DatabaseTable(Context context) { + mDatabaseOpenHelper = new DatabaseOpenHelper(context); + } + + private static class DatabaseOpenHelper extends SQLiteOpenHelper { + + private final Context mHelperContext; + private SQLiteDatabase mDatabase; + + private static final String FTS_TABLE_CREATE = + "CREATE VIRTUAL TABLE " + FTS_VIRTUAL_TABLE + + " USING fts3 (" + + COL_WORD + ", " + + COL_DEFINITION + ")"; + + DatabaseOpenHelper(Context context) { + super(context, DATABASE_NAME, null, DATABASE_VERSION); + mHelperContext = context; + } + + @Override + public void onCreate(SQLiteDatabase db) { + mDatabase = db; + mDatabase.execSQL(FTS_TABLE_CREATE); + } + + @Override + public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { + Log.w(TAG, "Upgrading database from version " + oldVersion + " to " + + newVersion + ", which will destroy all old data"); + db.execSQL("DROP TABLE IF EXISTS " + FTS_VIRTUAL_TABLE); + onCreate(db); + } + } +} +</pre> + + <h2 id="populate">Populate the Virtual Table</h2> + + <p>The table now needs data to store. The following code shows you how to read a text file + (located in <code>res/raw/definitions.txt</code>) that contains words and their definitions, how + to parse that file, and how to insert each line of that file as a row in the virtual table. This + is all done in another thread to prevent the UI from locking. Add the following code to your + <code>DatabaseOpenHelper</code> inner class.</p> + + <p class="note"><strong>Tip:</strong> You also might want to set up a callback to notify your UI + activity of this thread's completion.</p> + <pre> +private void loadDictionary() { + new Thread(new Runnable() { + public void run() { + try { + loadWords(); + } catch (IOException e) { + throw new RuntimeException(e); + } + } + }).start(); + } + +private void loadWords() throws IOException { + final Resources resources = mHelperContext.getResources(); + InputStream inputStream = resources.openRawResource(R.raw.definitions); + BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream)); + + try { + String line; + while ((line = reader.readLine()) != null) { + String[] strings = TextUtils.split(line, "-"); + if (strings.length < 2) continue; + long id = addWord(strings[0].trim(), strings[1].trim()); + if (id < 0) { + Log.e(TAG, "unable to add word: " + strings[0].trim()); + } + } + } finally { + reader.close(); + } +} + +public long addWord(String word, String definition) { + ContentValues initialValues = new ContentValues(); + initialValues.put(COL_WORD, word); + initialValues.put(COL_DEFINITION, definition); + + return mDatabase.insert(FTS_VIRTUAL_TABLE, null, initialValues); +} +</pre> + + <p>Call the <code>loadDictionary()</code> method wherever appropriate to populate the table. A + good place would be in the {@link android.database.sqlite.SQLiteOpenHelper#onCreate onCreate()} + method of the <code>DatabaseOpenHelper</code> class, right after you create the table:</p> + <pre> +@Override +public void onCreate(SQLiteDatabase db) { + mDatabase = db; + mDatabase.execSQL(FTS_TABLE_CREATE); + loadDictionary(); +} +</pre> + + <h2 id="search">Search for the Query</h2> + + <p>When you have the virtual table created and populated, use the query supplied by your {@link + android.widget.SearchView} to search the data. Add the following methods to the + <code>DatabaseTable</code> class to build a SQL statement that searches for the query:</p> + <pre> +public Cursor getWordMatches(String query, String[] columns) { + String selection = COL_WORD + " MATCH ?"; + String[] selectionArgs = new String[] {query+"*"}; + + return query(selection, selectionArgs, columns); +} + +private Cursor query(String selection, String[] selectionArgs, String[] columns) { + SQLiteQueryBuilder builder = new SQLiteQueryBuilder(); + builder.setTables(FTS_VIRTUAL_TABLE); + + Cursor cursor = builder.query(mDatabaseOpenHelper.getReadableDatabase(), + columns, selection, selectionArgs, null, null, null); + + if (cursor == null) { + return null; + } else if (!cursor.moveToFirst()) { + cursor.close(); + return null; + } + return cursor; +} +</pre> + + <p>Search for a query by calling <code>getWordMatches()</code>. Any matching results are returned + in a {@link android.database.Cursor} that you can iterate through or use to build a {@link android.widget.ListView}. + This example calls <code>getWordMatches()</code> in the <code>handleIntent()</code> method of the searchable + activity. Remember that the searchable activity receives the query inside of the {@link + android.content.Intent#ACTION_SEARCH} intent as an extra, because of the intent filter that you + previously created:</p> + <pre> +DatabaseTable db = new DatabaseTable(this); + +... + +private void handleIntent(Intent intent) { + + if (Intent.ACTION_SEARCH.equals(intent.getAction())) { + String query = intent.getStringExtra(SearchManager.QUERY); + Cursor c = db.getWordMatches(query, null); + //process Cursor and display results + } +} +</pre>
\ No newline at end of file diff --git a/docs/html/training/search/setup.jd b/docs/html/training/search/setup.jd new file mode 100644 index 0000000..044e422 --- /dev/null +++ b/docs/html/training/search/setup.jd @@ -0,0 +1,197 @@ +page.title=Setting Up the Search Interface +trainingnavtop=true +next.title=Storing and Searching for Data +next.link=search.html + +@jd:body + + <div id="tb-wrapper"> + <div id="tb"> + <h2>This lesson teaches you to</h2> + + <ul> + <li><a href="{@docRoot}training/search/setup.html#add-sv">Add the Search View to the Action + Bar</a></li> + + <li><a href="{@docRoot}training/search/setup.html#create-sc">Create a Searchable + Configuration</a></li> + + <li><a href="{@docRoot}training/search/setup.html#create-sa">Create a Searchable + Activity</a></li> + </ul> + + <h2>You should also read:</h2> + + <ul> + <li><a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a></li> + </ul> + </div> + </div> + + <p>Beginning in Android 3.0, using the {@link android.widget.SearchView} widget as an item in + the action bar is the preferred way to provide search in your app. Like with all items in + the action bar, you can define the {@link android.widget.SearchView} to show at all times, only + when there is room, or as a collapsible action, which displays the {@link + android.widget.SearchView} as an icon initially, then takes up the entire action bar as a search + field when the user clicks the icon.</p> + + <p class="note"><strong>Note:</strong> Later in this class, you will learn how to make your + app compatible down to Android 2.1 (API level 7) for devices that do not support + {@link android.widget.SearchView}.</p> + + <h2 id="add-sv">Add the Search View to the Action Bar</h2> + + <p>To add a {@link android.widget.SearchView} widget to the action bar, create a file named + <code>res/menu/options_menu.xml</code> in your project and add the following code to the file. + This code defines how to create the search item, such as the icon to use and the title of the + item. The <code>collapseActionView</code> attribute allows your {@link android.widget.SearchView} + to expand to take up the whole action bar and collapse back down into a + normal action bar item when not in use. Because of the limited action bar space on handset devices, + using the <code>collapsibleActionView</code> attribute is recommended to provide a better + user experience.</p> + <pre> +<?xml version="1.0" encoding="utf-8"?> +<menu xmlns:android="http://schemas.android.com/apk/res/android"> + <item android:id="@+id/search" + android:title="@string/search_title" + android:icon="@drawable/ic_search" + android:showAsAction="collapseActionView|ifRoom" + android:actionViewClass="android.widget.SearchView" /> +</menu> +</pre> + + <p class="note"><strong>Note:</strong> If you already have an existing XML file for your menu + items, you can add the <code><item></code> element to that file instead.</p> + + <p>To display the {@link android.widget.SearchView} in the action bar, inflate the XML menu + resource (<code>res/menu/options_menu.xml</code>) in the {@link + android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()} method of your activity:</p> + <pre> +@Override +public boolean onCreateOptionsMenu(Menu menu) { + MenuInflater inflater = getMenuInflater(); + inflater.inflate(R.menu.options_menu, menu); + + return true; +} +</pre> + + <p>If you run your app now, the {@link android.widget.SearchView} appears in your app's action + bar, but it isn't functional. You now need to define <em>how</em> the {@link + android.widget.SearchView} behaves.</p> + + <h2 id="create-sc">Create a Searchable Configuration</h2> + + <p>A <a href="http://developer.android.com/guide/topics/search/searchable-config.html">searchable + configuration</a> defines how the {@link android.widget.SearchView} behaves and is defined in a + <code>res/xml/searchable.xml</code> file. At a minimum, a searchable configuration must contain + an <code>android:label</code> attribute that has the same value as the + <code>android:label</code> attribute of the <a href="{@docRoot}guide/topics/manifest/application-element.html"><application></a> or + <a href="{@docRoot}guide/topics/manifest/activity-element.html"><activity></a> element in your Android manifest. + However, we also recommend adding an <code>android:hint</code> attribute to give the user an idea of what to enter into the search + box:</p> + <pre> +<?xml version="1.0" encoding="utf-8"?> + +<searchable xmlns:android="http://schemas.android.com/apk/res/android" + android:label="@string/app_name" + android:hint="@string/search_hint" /> +</pre> + + <p>In your application's manifest file, declare a <a href="{@docRoot}guide/topics/manifest/meta-data-element.html"> + <code><meta-data></code></a> element that points to the <code>res/xml/searchable.xml</code> file, + so that your application knows where to find it. Declare the element in an <code><activity></code> + that you want to display the {@link android.widget.SearchView} in:</p> + <pre> +<activity ... > + ... + <meta-data android:name="android.app.searchable" + android:resource="@xml/searchable" /> + +</activity> +</pre> + + <p>In the {@link android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()} method that you + created before, associate the searchable configuration with the {@link android.widget.SearchView} + by calling {@link android.widget.SearchView#setSearchableInfo}:</p> + <pre> +@Override +public boolean onCreateOptionsMenu(Menu menu) { + MenuInflater inflater = getMenuInflater(); + inflater.inflate(R.menu.options_menu, menu); + + // Associate searchable configuration with the SearchView + SearchManager searchManager = + (SearchManager) getSystemService(Context.SEARCH_SERVICE); + SearchView searchView = + (SearchView) menu.findItem(R.id.search).getActionView(); + searchView.setSearchableInfo( + searchManager.getSearchableInfo(getComponentName())); + + return true; +} +</pre> + + <p>The call to {@link android.app.SearchManager#getSearchableInfo getSearchableInfo()} obtains a + {@link android.app.SearchableInfo} object that is created from the searchable configuration XML + file. When the searchable configuration is correctly associated with your {@link + android.widget.SearchView}, the {@link android.widget.SearchView} starts an activity with the + {@link android.content.Intent#ACTION_SEARCH} intent when a user submits a query. You now need an + activity that can filter for this intent and handle the search query.</p> + + <h2 id="create-sa">Create a Searchable Activity</h2> + + <p>A {@link android.widget.SearchView} tries to start an activity with the {@link + android.content.Intent#ACTION_SEARCH} when a user submits a search query. A searchable activity + filters for the {@link android.content.Intent#ACTION_SEARCH} intent and searches for the query in + some sort of data set. To create a searchable activity, declare an activity of your choice to + filter for the {@link android.content.Intent#ACTION_SEARCH} intent:</p> + <pre> +<activity android:name=".SearchResultsActivity" ... > + ... + <intent-filter> + <action android:name="android.intent.action.SEARCH" /> + </intent-filter> + ... +</activity> +</pre> + + <p>In your searchable activity, handle the {@link android.content.Intent#ACTION_SEARCH} intent by + checking for it in your {@link android.app.Activity#onCreate onCreate()} method.</p> + + <p class="note"><strong>Note:</strong> If your searchable activity launches in single top mode + (<code>android:launchMode="singleTop"</code>), also handle the {@link + android.content.Intent#ACTION_SEARCH} intent in the {@link android.app.Activity#onNewIntent + onNewIntent()} method. In single top mode, only one instance of your activity is created and + subsequent calls to start your activity do not create a new activity on the + stack. This launch mode is useful so users can perform searches from the same activity + without creating a new activity instance every time.</p> + <pre> +public class SearchResultsActivity extends Activity { + + @Override + public void onCreate(Bundle savedInstanceState) { + ... + handleIntent(getIntent()); + } + + @Override + protected void onNewIntent(Intent intent) { + ... + handleIntent(intent); + } + + private void handleIntent(Intent intent) { + + if (Intent.ACTION_SEARCH.equals(intent.getAction())) { + String query = intent.getStringExtra(SearchManager.QUERY); + //use the query to search your data somehow + } + } + ... +} +</pre> + + <p>If you run your app now, the {@link android.widget.SearchView} can accept the user's query and + start your searchable activity with the {@link android.content.Intent#ACTION_SEARCH} intent. It + is now up to you to figure out how to store and search your data given a query.</p>
\ No newline at end of file diff --git a/docs/html/training/sharing/receive.jd b/docs/html/training/sharing/receive.jd index cc55967..a0a5bc8 100644 --- a/docs/html/training/sharing/receive.jd +++ b/docs/html/training/sharing/receive.jd @@ -34,7 +34,7 @@ Intent Filters</a></li> from applications. Think about how users interact with your application, and what data types you want to receive from other applications. For example, a social networking application would likely be interested in receiving text content, like an interesting web URL, from another app. The -<a href="https://market.android.com/details?id=com.google.android.apps.plus">Google+ Android +<a href="https://play.google.com/store/details?id=com.google.android.apps.plus">Google+ Android application</a> accepts both text <em>and</em> single or multiple images. With this app, a user can easily start a new Google+ post with photos from the Android Gallery app.</p> diff --git a/docs/html/training/tv/index.jd b/docs/html/training/tv/index.jd new file mode 100644 index 0000000..ae13c4a --- /dev/null +++ b/docs/html/training/tv/index.jd @@ -0,0 +1,52 @@ +page.title=Designing for TV + +trainingnavtop=true +startpage=true +next.title=Optimizing layouts for TV +next.link=optimizing-layouts-tv.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<!-- Required platform, tools, add-ons, devices, knowledge, etc. --> +<h2>Dependencies and prerequisites</h2> +<ul> + <li>Android 2.0 (API Level 5) or higher</li> +</ul> + +</div> +</div> +<p> + Smart TVs powered by Android bring your favorite Android apps to the best screen in your house. + Thousands of apps in the Google Play Store are already optimized for TVs. This class shows how + you can optimize your Android app for TVs, including how to build a layout that + works great when the user is ten feet away and navigating with a remote control. +</p> + +<h2>Lessons</h2> + +<dl> + <dt><b><a href="optimizing-layouts-tv.html">Optimizing Layouts for TV</a></b></dt> + <dd>Shows you how to optimize app layouts for TV screens, which have some unique characteristics such as: + <ul> + <li>permanent "landscape" mode</li> + <li>high-resolution displays</li> + <li>"10 foot UI" environment.</li> + </ul> + </dd> + + <dt><b><a href="optimizing-navigation-tv.html">Optimizing Navigation for TV</a></b></dt> + <dd>Shows you how to design navigation for TVs, including: + <ul> + <li>handling D-pad navigation</li> + <li>providing navigational feedback</li> + <li>providing easily-accessible controls on the screen.</li> + </ul> + </dd> + + <dt><b><a href="unsupported-features-tv.html">Handling features not supported on TV</a></b></dt> + <dd>Lists the hardware features that are usually not available on TVs. This lesson also shows you how to + provide alternatives for missing features or check for missing features and disable code at run time.</dd> +</dl>
\ No newline at end of file diff --git a/docs/html/training/tv/optimizing-layouts-tv.jd b/docs/html/training/tv/optimizing-layouts-tv.jd new file mode 100644 index 0000000..e4a8e69 --- /dev/null +++ b/docs/html/training/tv/optimizing-layouts-tv.jd @@ -0,0 +1,246 @@ +page.title=Optimizing Layouts for TV +parent.title=Designing for TV +parent.link=index.html + +trainingnavtop=true +next.title=Optimizing Navigation for TV +next.link=optimizing-navigation-tv.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#DesignLandscapeLayouts">Design Landscape Layouts</a></li> + <li><a href="#MakeTextControlsEasyToSee">Make Text and Controls Easy to See</a></li> + <li><a href="#DesignForLargeScreens">Design for High-Density Large Screens</a></li> + <li><a href="#HandleLargeBitmaps">Design to Handle Large Bitmaps</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a></li> +</ul> + +</div> +</div> + +<p> +When your application is running on a television set, you should assume that the user is sitting about +ten feet away from the screen. This user environment is referred to as the +<a href="http://en.wikipedia.org/wiki/10-foot_user_interface">10-foot UI</a>. To provide your +users with a usable and enjoyable experience, you should style and lay out your UI accordingly.. +</p> +<p> +This lesson shows you how to optimize layouts for TV by: +</p> +<ul> + <li>Providing appropriate layout resources for landscape mode.</li> + <li>Ensuring that text and controls are large enough to be visible from a distance.</li> + <li>Providing high resolution bitmaps and icons for HD TV screens.</li> +</ul> + +<h2 id="DesignLandscapeLayouts">Design Landscape Layouts</h2> + +<p> +TV screens are always in landscape orientation. Follow these tips to build landscape layouts optimized for TV screens: +</p> +<ul> + <li>Put on-screen navigational controls on the left or right side of the screen and save the + vertical space for content.</li> + <li>Create UIs that are divided into sections, by using <a href="{@docRoot}guide/topics/fundamentals/fragments.html">Fragments</a> + and use view groups like {@link android.widget.GridView} instead + of {@link android.widget.ListView} to make better use of the + horizontal screen space.</li> + <li>Use view groups such as {@link android.widget.RelativeLayout} + or {@link android.widget.LinearLayout} to arrange views. + This allows the Android system to adjust the position of the views to the size, alignment, + aspect ratio, and pixel density of the TV screen.</li> + <li>Add sufficient margins between layout controls to avoid a cluttered UI.</li> +</ul> + +<p> +For example, the following layout is optimized for TV: +</p> + +<img src="{@docRoot}images/training/panoramio-grid.png" /> + +<p> +In this layout, the controls are on the lefthand side. The UI is displayed within a +{@link android.widget.GridView}, which is well-suited to landscape orientation. +In this layout both GridView and Fragment have the width and height set +dynamically, so they can adjust to the screen resolution. Controls are added to the left side Fragment programatically at runtime. +The layout file for this UI is {@code res/layout-land-large/photogrid_tv.xml}. +(This layout file is placed in {@code layout-land-large} because TVs have large screens with landscape orientation. For details refer to +<a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a>.)</p> + +res/layout-land-large/photogrid_tv.xml +<pre> +<RelativeLayout + android:layout_width="fill_parent" + android:layout_height="fill_parent" > + + <fragment + android:id="@+id/leftsidecontrols" + android:layout_width="0dip" + android:layout_marginLeft="5dip" + android:layout_height="match_parent" /> + + <GridView + android:id="@+id/gridview" + android:layout_width="wrap_content" + android:layout_height="wrap_content" /> + +</RelativeLayout> +</pre> + +<p> +To set up action bar items on the left side of the screen, you can also include the <a +href="http://code.google.com/p/googletv-android-samples/source/browse/#git%2FLeftNavBarLibrary"> +Left navigation bar library</a> in your application to set up action items on the left side +of the screen, instead of creating a custom Fragment to add controls: +</p> + +<pre> +LeftNavBar bar = (LeftNavBarService.instance()).getLeftNavBar(this); +</pre> + +<p> +When you have an activity in which the content scrolls vertically, always use a left navigation bar; +otherwise, your users have to scroll to the top of the content to switch between the content view and +the ActionBar. Look at the +<a href="http://code.google.com/p/googletv-android-samples/source/browse/#git%2FLeftNavBarDemo"> +Left navigation bar sample app</a> to see how to simple it is to include the left navigation bar in your app. +</p> + +<h2 id="MakeTextControlsEasyToSee">Make Text and Controls Easy to See</h2> +<p> +The text and controls in a TV application's UI should be easily visible and navigable from a distance. +Follow these tips to make them easier to see from a distance : +</p> + +<ul> + <li>Break text into small chunks that users can quickly scan.</li> + <li>Use light text on a dark background. This style is easier to read on a TV.</li> + <li>Avoid lightweight fonts or fonts that have both very narrow and very broad strokes. Use simple sans-serif + fonts and use anti-aliasing to increase readability.</li> + <li>Use Android's standard font sizes: + <pre> + <TextView + android:id="@+id/atext" + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:gravity="center_vertical" + android:singleLine="true" + android:textAppearance="?android:attr/textAppearanceMedium"/> + </pre></li> + <li>Ensure that all your view widgets are large enough to be clearly visible to someone sitting 10 feet away + from the screen (this distance is greater for very large screens). The best way to do this is to use + layout-relative sizing rather than absolute sizing, and density-independent pixel units instead of absolute + pixel units. For example, to set the width of a widget, use wrap_content instead of a pixel measurement, + and to set the margin for a widget, use dip instead of px values. + </li> +</ul> +<p> + +</p> + +<h2 id="DesignForLargeScreens">Design for High-Density Large Screens</h2> + +<p> +The common HDTV display resolutions are 720p, 1080i, and 1080p. Design your UI for 1080p, and then +allow the Android system to downscale your UI to 720p if necessary. In general, downscaling (removing pixels) +does not degrade the UI (Notice that the converse is not true; you should avoid upscaling because it degrades +UI quality). +</p> + +<p> +To get the best scaling results for images, provide them as <a href="{@docRoot}guide/developing/tools/draw9patch.html"> +9-patch image</a> elements if possible. +If you provide low quality or small images in your layouts, they will appear pixelated, fuzzy, or grainy. This +is not a good experience for the user. Instead, use high-quality images. +</p> + +<p> +For more information on optimizing apps for large screens see <a href="{@docRoot}training/multiscreen/index.html"> +Designing for multiple screens</a>. +</p> + +<h2 id="HandleLargeBitmaps">Design to Handle Large Bitmaps</h2> + +<p> +The Android system has a limited amount of memory, so downloading and storing high-resolution images can often +cause out-of-memory errors in your app. To avoid this, follow these tips: +</p> + +<ul> + <li>Load images only when they're displayed on the screen. For example, when displaying multiple images in + a {@link android.widget.GridView} or + {@link android.widget.Gallery}, only load an image when + {@link android.widget.Adapter#getView(int, View, ViewGroup) getView()} + is called on the View's {@link android.widget.Adapter}. + </li> + <li>Call {@link android.graphics.Bitmap#recycle()} on + {@link android.graphics.Bitmap} views that are no longer needed. + </li> + <li>Use {@link java.lang.ref.WeakReference} for storing references + to {@link android.graphics.Bitmap} objects in a in-memory + <a href="{@link java.util.Collection}.</li> + <li>If you fetch images from the network, use {@link android.os.AsyncTask} + to fetch them and store them on the SD card for faster access. + Never do network transactions on the application's UI thread. + </li> + <li>Scale down really large images to a more appropriate size as you download them; otherwise, downloading the image + itself may cause an "Out of Memory" exception. Here is sample code that scales down images while downloading: + + <pre> + // Get the source image's dimensions + BitmapFactory.Options options = new BitmapFactory.Options(); + // This does not download the actual image, just downloads headers. + options.inJustDecodeBounds = true; + BitmapFactory.decodeFile(IMAGE_FILE_URL, options); + // The actual width of the image. + int srcWidth = options.outWidth; + // The actual height of the image. + int srcHeight = options.outHeight; + + // Only scale if the source is bigger than the width of the destination view. + if(desiredWidth > srcWidth) + desiredWidth = srcWidth; + + // Calculate the correct inSampleSize/scale value. This helps reduce memory use. It should be a power of 2. + int inSampleSize = 1; + while(srcWidth / 2 > desiredWidth){ + srcWidth /= 2; + srcHeight /= 2; + inSampleSize *= 2; + } + + float desiredScale = (float) desiredWidth / srcWidth; + + // Decode with inSampleSize + options.inJustDecodeBounds = false; + options.inDither = false; + options.inSampleSize = inSampleSize; + options.inScaled = false; + // Ensures the image stays as a 32-bit ARGB_8888 image. + // This preserves image quality. + options.inPreferredConfig = Bitmap.Config.ARGB_8888; + + Bitmap sampledSrcBitmap = BitmapFactory.decodeFile(IMAGE_FILE_URL, options); + + // Resize + Matrix matrix = new Matrix(); + matrix.postScale(desiredScale, desiredScale); + Bitmap scaledBitmap = Bitmap.createBitmap(sampledSrcBitmap, 0, 0, + sampledSrcBitmap.getWidth(), sampledSrcBitmap.getHeight(), matrix, true); + sampledSrcBitmap = null; + + // Save + FileOutputStream out = new FileOutputStream(LOCAL_PATH_TO_STORE_IMAGE); + scaledBitmap.compress(Bitmap.CompressFormat.JPEG, 100, out); + scaledBitmap = null; + </pre> + </li> </ul>
\ No newline at end of file diff --git a/docs/html/training/tv/optimizing-navigation-tv.jd b/docs/html/training/tv/optimizing-navigation-tv.jd new file mode 100644 index 0000000..bb78258 --- /dev/null +++ b/docs/html/training/tv/optimizing-navigation-tv.jd @@ -0,0 +1,206 @@ +page.title=Optimizing Navigation for TV +parent.title=Designing for TV +parent.link=index.html + +trainingnavtop=true +previous.title=Optimizing Layouts for TV +previous.link=optimizing-layouts-tv.html +next.title=Handling Features Not Supported on TV +next.link=unsupported-features-tv.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#HandleDpadNavigation">Handle D-pad Navigation</a></li> + <li><a href="#HandleFocusSelection">Provide Clear Visual Indication for Focus and Selection</a></li> + <li><a href="#DesignForEasyNavigation">Design for Easy Navigation</a></li> +</ol> + +<h2>You should also read</h2> +<ul> + <li><a href="{@docRoot}training/design-navigation/index.html">Designing Effective Navigation</a></li> +</ul> + +</div> +</div> + +<p> +An important aspect of the user experience when operating a TV is the direct human interface: a remote control. +As you optimize your Android application for TVs, you should pay special attention to how the user actually navigates +around your application when using a remote control instead of a touchscreen. +</p> +<p> +This lesson shows you how to optimize navigation for TV by: +</p> + +<ul> + <li>Ensuring all layout controls are D-pad navigable.</li> + <li>Providing highly obvious feedback for UI navigation.</li> + <li>Placing layout controls for easy access.</li> +</ul> + +<h2 id="HandleDpadNavigation">Handle D-pad Navigation</h2> + +<p> +On a TV, users navigate with controls on a TV remote, using either a D-pad or arrow keys. +This limits movement to up, down, left, and right. +To build a great TV-optimized app, you must provide a navigation scheme in which the user can +quickly learn how to navigate your app using the remote. +</p> + +<p> +When you design navigation for D-pad, follow these guidelines: +</p> + +<ul> + <li>Ensure that the D-pad can navigate to all the visible controls on the screen.</li> + <li>For scrolling lists with focus, D-pad up/down keys scroll the list and Enter key selects an item in the list. Ensure that users can + select an element in the list and that the list still scrolls when an element is selected.</li> + <li>Ensure that movement between controls is straightforward and predictable.</li> +</ul> + +<p> +Android usually handles navigation order between layout elements automatically, so you don't need to do anything extra. If the screen layout +makes navigation difficult, or if you want users to move through the layout in a specific way, you can set up explicit navigation for your +controls. +For example, for an {@code android.widget.EditText}, to define the next control to receive focus, use: +<pre> +<EditText android:id="@+id/LastNameField" android:nextFocusDown="@+id/FirstNameField"\> +</pre> +The following table lists all of the available navigation attributes: +</p> + +<table> +<tr> +<th>Attribute</th> +<th>Function</th> +</tr> +<tr> +<td>{@link android.R.attr#nextFocusDown}</td> +<td>Defines the next view to receive focus when the user navigates down.</td> +</tr> +<tr> +<td>{@link android.R.attr#nextFocusLeft}</td> +<td>Defines the next view to receive focus when the user navigates left.</td> +</tr> +<tr> +<td>{@link android.R.attr#nextFocusRight}</td> +<td>Defines the next view to receive focus when the user navigates right.</td> +</tr> +<tr> +<td>{@link android.R.attr#nextFocusUp}</td> +<td>Defines the next view to receive focus when the user navigates up.</td> +</tr> +</table> + +<p> +To use one of these explicit navigation attributes, set the value to the ID (android:id value) of another widget in the layout. You should set +up the navigation order as a loop, so that the last control directs focus back to the first one. +</p> + +<p> +Note: You should only use these attributes to modify the navigation order if the default order that the system applies does not work well. +</p> + +<h2 id="HandleFocusSelection">Provide Clear Visual Indication for Focus and Selection</h2> + +<p> +Use appropriate color highlights for all navigable and selectable elements in the UI. This makes it easy for users to know whether the control +is currently focused or selected when they navigate with a D-pad. Also, use uniform highlight scheme across your application. +</p> + +<p> +Android provides <a href="{@docRoot}guide/topics/resources/drawable-resource.html#StateList">Drawable State List Resources</a> to implement highlights +for selected and focused controls. For example: +</p> + +res/drawable/button.xml: +<pre> +<?xml version="1.0" encoding="utf-8"?> +<selector xmlns:android="http://schemas.android.com/apk/res/android"> + <item android:state_pressed="true" + android:drawable="@drawable/button_pressed" /> <!-- pressed --> + <item android:state_focused="true" + android:drawable="@drawable/button_focused" /> <!-- focused --> + <item android:state_hovered="true" + android:drawable="@drawable/button_focused" /> <!-- hovered --> + <item android:drawable="@drawable/button_normal" /> <!-- default --> +</selector> +</pre> + +<p> +This layout XML applies the above state list drawable to a {@link android.widget.Button}: +</p> +<pre> +<Button + android:layout_height="wrap_content" + android:layout_width="wrap_content" + android:background="@drawable/button" /> +</pre> + +<p> +Provide sufficient padding within the focusable and selectable controls so that the highlights around them are clearly visible. +</p> + +<h2 id="DesignForEasyNavigation">Design for Easy Navigation</h2> + +<p> +Users should be able to navigate to any UI control with a couple of D-pad clicks. Navigation should be easy and intuitive to +understand. For any non-intuitive actions, provide users with written help, using a dialog triggered by a help button or action bar icon. +</p> + +<p> +Predict the next screen that the user will want to navigate to and provide one click navigation to it. If the current screen UI is very sparse, +consider making it a multi pane screen. Use fragments for making multi-pane screens. For example, consider the multi-pane UI below with continent names +on the left and list of cool places in each continent on the right. +</p> + +<img src="{@docRoot}images/training/cool-places.png" alt="" /> + +<p> +The above UI consists of three Fragments - <code>left_side_action_controls</code>, <code>continents</code> and +<code>places</code> - as shown in its layout +xml file below. Such multi-pane UIs make D-pad navigation easier and make good use of the horizontal screen space for +TVs. +</p> +res/layout/cool_places.xml +<pre> +<LinearLayout + android:layout_width="match_parent" + android:layout_height="match_parent" + android:orientation="horizontal" + > + <fragment + android:id="@+id/left_side_action_controls" + android:layout_width="0px" + android:layout_height="match_parent" + android:layout_marginLeft="10dip" + android:layout_weight="0.2"/> + <fragment + android:id="@+id/continents" + android:layout_width="0px" + android:layout_height="match_parent" + android:layout_marginLeft="10dip" + android:layout_weight="0.2"/> + + <fragment + android:id="@+id/places" + android:layout_width="0px" + android:layout_height="match_parent" + android:layout_marginLeft="10dip" + android:layout_weight="0.6"/> + +</LinearLayout> +</pre> + +<p> +Also, notice in the UI layout above action controls are on the left hand side of a vertically scrolling list to make +them easily accessible using D-pad. +In general, for layouts with horizontally scrolling components, place action controls on left or right hand side and +vice versa for vertically scrolling components. +</p> + diff --git a/docs/html/training/tv/unsupported-features-tv.jd b/docs/html/training/tv/unsupported-features-tv.jd new file mode 100644 index 0000000..6b0f8c8 --- /dev/null +++ b/docs/html/training/tv/unsupported-features-tv.jd @@ -0,0 +1,156 @@ +page.title=Handling Features Not Supported on TV +parent.title=Designing for TV +parent.link=index.html + +trainingnavtop=true +previous.title=Optimizing Navigation for TV +previous.link=optimizing-navigation-tv.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>This lesson teaches you to</h2> +<ol> + <li><a href="#WorkaroundUnsupportedFeatures">Work Around Features Not Supported on TV</a></li> + <li><a href="#CheckAvailableFeatures">Check for Available Features at Runtime</a></li> +</ol> + +</div> +</div> + +<p> +TVs are much different from other Android-powered devices: +</p> +<ul> + <li>They're not mobile.</li> + <li>Out of habit, people use them for watching media with little or no interaction.</li> + <li>People interact with them from a distance.</li> +</ul> + +<p> +Because TVs have a different purpose from other devices, they usually don't have hardware features +that other Android-powered devices often have. For this reason, the Android system does not +support the following features for a TV device: +<table> +<tr> +<th>Hardware</th> +<th>Android feature descriptor</th> +</tr> +<tr> +<td>Camera</td> +<td>android.hardware.camera</td> +</tr> +<tr> +<td>GPS</td> +<td>android.hardware.location.gps</td> +</tr> +<tr> +<td>Microphone</td> +<td>android.hardware.microphone</td> +</tr> +<tr> +<td>Near Field Communications (NFC)</td> +<td>android.hardware.nfc</td> +</tr> +<tr> +<td>Telephony</td> +<td>android.hardware.telephony</td> +</tr> +<tr> +<td>Touchscreen</td> +<td>android.hardware.touchscreen</td> +</tr> +</table> +</p> + +<p> +This lesson shows you how to work around features that are not available on TV by: +<ul> + <li>Providing work arounds for some non-supported features.</li> + <li>Checking for available features at runtime and conditionally activating/deactivating certain code + paths based on availability of those features.</li> +</ul> +</p> + + +<h2 id="WorkaroundUnsupportedFeatures">Work Around Features Not Supported on TV</h2> + +<p> +Android doesn't support touchscreen interaction for TV devices, most TVs don't have touch screens, +and interacting with a TV using a touchscreen is not consistent with the 10 foot environment. For +these reasons, users interact with Android-powered TVs using a remote. In consideration of this, +ensure that every control in your app can be accessed with the D-pad. Refer back to the previous two lessons +<a href="{@docRoot}training/tv/optimizing-layouts-tv">Optimizing Layouts for TV</a> and +<a href="{@docRoot}training/tv/optimizing-navigation-tv">Optimize Navigation for TV</a> for more details +on this topic. The Android system assumes that a device has a touchscreen, so if you want your application +to run on a TV, you must <strong>explicitly</strong> disable the touchscreen requirement in your manifest file: +<pre> +<uses-feature android:name="android.hardware.touchscreen" android:required="false"/> +</pre> +</p> + +<p> +Although a TV doesn't have a camera, you can still provide a photography-related application on a TV. +For example, if you have an app that takes, views and edits photos, you can disable its picture-taking +functionality for TVs and still allow users to view and even edit photos. The next section talks about how to +deactivate or activate specific functions in the application based on runtime device type detection. +</p> + +<p> +Because TVs are stationary, indoor devices, they don't have built-in GPS. If your application uses location +information, allow users to search for a location or use a "static" location provider to get +a location from the zip code configured during the TV setup. +<pre> +LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE); +Location location = locationManager.getLastKnownLocation("static"); +Geocoder geocoder = new Geocoder(this); +Address address = null; + +try { + address = geocoder.getFromLocation(location.getLatitude(), location.getLongitude(), 1).get(0); + Log.d("Zip code", address.getPostalCode()); + +} catch (IOException e) { + Log.e(TAG, "Geocoder error", e); +} +</pre> +</p> + +<p> +TVs usually don't support microphones, but if you have an application that uses voice control, +you can create a mobile device app that takes voice input and then acts as a remote control for a TV. +</p> + +<h2 id="CheckAvailableFeatures">Check for Available Features at Runtime</h2> + +<p> +To check if a feature is available at runtime, call +{@link android.content.pm.PackageManager#hasSystemFeature(String)}. + This method takes a single argument : a string corresponding to the +feature you want to check. For example, to check for touchscreen, use +{@link android.content.pm.PackageManager#hasSystemFeature(String)} with the argument +{@link android.content.pm.PackageManager#FEATURE_TOUCHSCREEN}. +</p> + +<p> +The following code snippet demonstrates how to detect device type at runtime based on supported features: + +<pre> +// Check if android.hardware.telephony feature is available. +if (getPackageManager().hasSystemFeature("android.hardware.telephony")) { + Log.d("Mobile Test", "Running on phone"); +// Check if android.hardware.touchscreen feature is available. +} else if (getPackageManager().hasSystemFeature("android.hardware.touchscreen")) { + Log.d("Tablet Test", "Running on devices that don't support telphony but have a touchscreen."); +} else { + Log.d("TV Test", "Running on a TV!"); +} +</pre> +</p> + +<p> +This is just one example of using runtime checks to deactivate app functionality that depends on features +that aren't available on TVs. +</p>
\ No newline at end of file |