1 page.title=Designing for Seamlessness 2 @jd:body 3 4 <p>Even if your application is fast and responsive, certain design decisions can 5 still cause problems for users — because of unplanned interactions with 6 other applications or dialogs, inadvertent loss of data, unintended blocking, 7 and so on. To avoid these problems, it helps to understand the context in which 8 your applications run and the system interactions that can affect your 9 application. In short, you should strive to develop an application that 10 interacts seamlessly with the system and with other applications. </p> 11 12 <p>A common seamlessness problem is when an application's background process 13 — for example, a service or broadcast receiver — pops up a dialog in 14 response to some event. This may seem like harmless behavior, especially when 15 you are building and testing your application in isolation, on the emulator. 16 However, when your application is run on an actual device, your application may 17 not have user focus at the time your background process displays the dialog. So 18 it could end up that your application would display it's dialog behind the 19 active application, or it could take focus from the current application and 20 display the dialog in front of whatever the user was doing (such as dialing a 21 phone call, for example). That behavior would not work for your application or 22 for the user. </p> 23 24 <p>To avoid these problems, your application should use the proper system 25 facility for notifying the user — the 26 {@link android.app.Notification Notification} classes. Using 27 notifications, your application can signal the user that an event has 28 taken place, by displaying an icon in the status bar rather than taking 29 focus and interrupting the user.</p> 30 31 <p>Another example of a seamlessness problem is when an activity inadvertently 32 loses state or user data because it doesn't correctly implement the onPause() 33 and other lifecycle methods. Or, if your application exposes data intended to be 34 used by other applications, you should expose it via a ContentProvider, rather 35 than (for example) doing so through a world-readable raw file or database.</p> 36 37 <p>What those examples have in common is that they involve cooperating nicely 38 with the system and other applications. The Android system is designed to treat 39 applications as a sort of federation of loosely-coupled components, rather than 40 chunks of black-box code. This allows you as the developer to view the entire 41 system as just an even-larger federation of these components. This benefits you 42 by allowing you to integrate cleanly and seamlessly with other applications, and 43 so you should design your own code to return the favor.</p> 44 45 <p>This document discusses common seamlessness problems and how to avoid them. 46 It covers these topics: </p> 47 <ul> 48 <li><a href="#drop">Don't Drop Data</a></li> 49 <li><a href="#expose">Don't Expose Raw Data</a></li> 50 <li><a href="#interrupt">Don't Interrupt the User</a></li> 51 <li><a href="#threads">Got a Lot to Do? Do it in a Thread</a></li> 52 <li><a href="#multiple-activities">Don't Overload a Single Activity Screen</a></li> 53 <li><a href="#themes">Extend System Themes</a></li> 54 <li><a href="#flexui">Design Your UI to Work with Multiple Screen Resolutions</a></li> 55 <li><a href="#network">Assume the Network is Slow</a></li> 56 <li><a href="#keyboard">Don't Assume Touchscreen or Keyboard</a></li> 57 <li><a href="#battery">Do Conserve the Device Battery</a></li> 58 </ul> 59 60 <h2 id="drop">Don't Drop Data</h2> 61 62 <p>Always keep in mind that Android is a mobile platform. It may seem obvious to 63 say it, but it's important to remember that another Activity (such as the 64 "Incoming Phone Call" app) can pop up over your own Activity at any moment. 65 This will fire the onSaveInstanceState() and onPause() methods, and will likely result in 66 your application being killed.</p> 67 68 <p>If the user was editing data in your application when the other Activity 69 appeared, your application will likely lose that data when your application is 70 killed. Unless, of course, you save the work in progress first. The "Android 71 Way" is to do just that: Android applications that accept or edit input should 72 override the onSaveInstanceState() method and save their state in some appropriate 73 fashion. When the user revisits the application, she should be able to 74 retrieve her data.</p> 75 76 <p>A classic example of a good use of this behavior is a mail application. If the 77 user was composing an email when another Activity started up, the application 78 should save the in-process email as a draft.</p> 79 80 <h2 id="expose">Don't Expose Raw Data</h2> 81 82 <p>If you wouldn't walk down the street in your underwear, neither should your 83 data. While it's possible to expose certain kinds of application to the world 84 to read, this is usually not the best idea. Exposing raw data requires other 85 applications to understand your data format; if you change that format, you'll 86 break any other applications that aren't similarly updated.</p> 87 88 <p>The "Android Way" is to create a ContentProvider to expose your data to other 89 applications via a clean, well-thought-out, and maintainable API. Using a 90 ContentProvider is much like inserting a Java language interface to split up and 91 componentize two tightly-coupled pieces of code. This means you'll be able to 92 modify the internal format of your data without changing the interface exposed 93 by the ContentProvider, and this without affecting other applications.</p> 94 95 <h2 id="interrupt">Don't Interrupt the User</h2> 96 97 <p>If the user is running an application (such as the Phone application during a 98 call) it's a pretty safe bet he did it on purpose. That's why you should avoid 99 spawning activities except in direct response to user input from the current 100 Activity.</p> 101 102 <p>That is, don't call startActivity() from BroadcastReceivers or Services running in 103 the background. Doing so will interrupt whatever application is currently 104 running, and result in an annoyed user. Perhaps even worse, your Activity may 105 become a "keystroke bandit" and receive some of the input the user was in the 106 middle of providing to the previous Activity. Depending on what your 107 application does, this could be bad news.</p> 108 109 <p>Instead of spawning Activity UIs directly from the background, you should 110 instead use the NotificationManager to set Notifications. These will appear in 111 the status bar, and the user can then click on them at his leisure, to see 112 what your application has to show him.</p> 113 114 <p>(Note that all this doesn't apply to cases where your own Activity is already 115 in the foreground: in that case, the user expects to see your next Activity in 116 response to input.)</p> 117 118 <h2 id="threads">Got a Lot to Do? Do it in a Thread</h2> 119 120 <p>If your application needs to perform some expensive or long-running 121 computation, you should probably move it to a thread. This will prevent the 122 dreaded "Application Not Responding" dialog from being displayed to the user, 123 with the ultimate result being the fiery demise of your application.</p> 124 125 <p>By default, all code in an Activity as well as all its Views run in the same 126 thread. This is the same thread that also handles UI events. For example, when 127 the user presses a key, a key-down event is added to the Activity's main 128 thread's queue. The event handler system needs to dequeue and handle that 129 event quickly; if it doesn't, the system concludes after a few seconds that 130 the application is hung and offers to kill it for the user.</p> 131 132 <p>If you have long-running code, running it inline in your Activity will run it 133 on the event handler thread, effectively blocking the event handler. This will 134 delay input processing, and result in the ANR dialogs. To avoid this, move 135 your computations to a thread. This <a 136 href="responsiveness.html">Design for Responsiveness</a> document 137 discusses how to do that..</p> 138 139 <h2 id="multiple-activities">Don't Overload a Single Activity Screen</h2> 140 141 <p>Any application worth using will probably have several different screens. 142 When designing the screens of your UI, be sure to make use of multiple Activity 143 object instances.</p> 144 145 <p>Depending on your development background, you may interpret an Activity as 146 similar to something like a Java Applet, in that it is the entry point for 147 your application. However, that's not quite accurate: where an Applet subclass 148 is the single entry point for a Java Applet, an Activity should be thought of 149 as one of potentially several entry points to your application. The only 150 difference between your "main" Activity and any others you might have is that 151 the "main" one just happens to be the only one that expressed an interest in 152 the "android.intent.action.MAIN" action in your AndroidManifest..xml file.</p> 153 154 <p>So, when designing your application, think of your application as a federation 155 of Activity objects. This will make your code a lot more maintainable in the long 156 run, and as a nice side effect also plays nicely with Android's application 157 history and "backstack" model.</p> 158 159 <h2 id="themes">Extend System Themes</h2> 160 161 <p>When it comes to the look-and-feel of the user interface, it's important to 162 blend in nicely. Users are jarred by applications which contrast with the user 163 interface they've come to expect. When designing your UIs, you should try and 164 avoid rolling your own as much as possible. Instead, use a Theme. You 165 can override or extend those parts of the theme that you need to, but at least 166 you're starting from the same UI base as all the other applications. For all 167 the details, read <a href="{@docRoot}guide/topics/ui/themes.html">Applying Styles and Themes</a>.</p> 168 169 <h2 id="flexui">Design Your UI to Work with Multiple Screen Resolutions</h2> 170 171 <p>Different Android-powered devices will support different screen resolutions. 172 Some will even be able to change resolutions on the fly, such as by switching 173 to landscape mode. It's important to make sure your layouts and drawables 174 are flexible enough to display properly on a variety of device screens.</p> 175 176 <p>Fortunately, this is very easy to do. In brief, what you must do is 177 provide different versions of your artwork (if you use any) for the key 178 resolutions, and then design your layout to accommodate various dimensions. 179 (For example, avoid using hard-coded positions and instead use relative 180 layouts.) If you do that much, the system handles the rest, and your 181 application looks great on any device.</p> 182 183 <h2 id="network">Assume the Network is Slow</h2> 184 185 <p>Android devices will come with a variety of network-connectivity options. All 186 will have some data-access provision, though some will be faster than others. 187 The lowest common denominator, however, is GPRS, the non-3G data service for 188 GSM networks. Even 3G-capable devices will spend lots of time on non-3G 189 networks, so slow networks will remain a reality for quite a long time to 190 come.</p> 191 192 <p>That's why you should always code your applications to minimize network 193 accesses and bandwidth. You can't assume the network is fast, so you should 194 always plan for it to be slow. If your users happen to be on faster networks, 195 then that's great — their experience will only improve. You want to avoid the 196 inverse case though: applications that are usable some of the time, but 197 frustratingly slow the rest based on where the user is at any given moment are 198 likely to be unpopular.</p> 199 200 <p>One potential gotcha here is that it's very easy to fall into this trap if 201 you're using the emulator, since the emulator uses your desktop computer's 202 network connection. That's almost guaranteed to be much faster than a cell 203 network, so you'll want to change the settings on the emulator that simulate 204 slower network speeds. You can do this in Eclipse, in the "Emulator Settings" 205 tab of your launch configuration or via a <a 206 href="{@docRoot}guide/developing/tools/emulator.html#netspeed">command-line 207 option</a> when starting the emulator.</p> 208 209 <h2 id="keyboard">Don't Assume Touchscreen or Keyboard</h2> 210 211 <p> 212 Android will support a variety of handset form-factors. That's a fancy way of 213 saying that some Android devices will have full "QWERTY" keyboards, while 214 others will have 40-key, 12-key, or even other key configurations. Similarly, 215 some devices will have touch-screens, but many won't. 216 </p><p> 217 When building your applications, keep that in mind. Don't make assumptions 218 about specific keyboard layouts -- unless, of course, you're really interested 219 in restricting your application so that it can only be used on those devices. 220 </p> 221 222 <h2 id="battery">Do Conserve the Device Battery</h2> 223 <p> 224 A mobile device isn't very mobile if it's constantly plugged into the 225 wall. Mobile devices are battery-powered, and the longer we can make that 226 battery last on a charge, the happier everyone is — especially the user. 227 Two of the biggest consumers of battery power are the processor, and the 228 radio; that's why it's important to write your applications to do as little 229 work as possible, and use the network as infrequently as possible. 230 </p><p> 231 Minimizing the amount of processor time your application uses really comes 232 down to <a href="performance.html">writing efficient 233 code</a>. To minimize the power drain from using the radio, be sure to handle 234 error conditions gracefully, and only fetch what you need. For example, don't 235 constantly retry a network operation if one failed. If it failed once, it's 236 likely because the user has no reception, so it's probably going to fail again 237 if you try right away; all you'll do is waste battery power. 238 </p><p> 239 Users are pretty smart: if your program is power-hungry, you can count on 240 them noticing. The only thing you can be sure of at that point is that your 241 program won't stay installed very long. 242 </p> 243
