Dirk Dougherty | 22558d0 | 2009-12-10 16:25:06 -0800 | [diff] [blame] | 1 | page.title=Future-Proofing Your Apps |
Scott Main | 796ce77 | 2011-02-16 10:04:45 -0800 | [diff] [blame] | 2 | parent.title=Articles |
| 3 | parent.link=../browser.html?tag=article |
Dirk Dougherty | 22558d0 | 2009-12-10 16:25:06 -0800 | [diff] [blame] | 4 | @jd:body |
| 5 | |
| 6 | <p>It's important to implement your application so that it will not break as new |
| 7 | versions of the Android platform are loaded onto the users device. The list |
| 8 | below is based on our observations of five ways that we've seen bad apps fail. |
| 9 | You can think of these as "anti-patterns" (that is, techniques to avoid) for |
| 10 | Android development.</p> |
| 11 | |
| 12 | <p>If your application uses any of the dubious techniques below, break out |
| 13 | your IDE and duct tape, spackle, and patch up the app.</p> |
| 14 | |
| 15 | <p><b>Technique to Avoid, #1: Using Internal APIs</b></p> |
| 16 | |
| 17 | <p>Even |
| 18 | though we've always strongly advised against doing so, some developers |
| 19 | have chosen to use unsupported or internal APIs. For instance, many |
| 20 | developers are using the internal brightness control and bluetooth |
| 21 | toggle APIs that were present in 1.0 and 1.1. A bug -- which was |
| 22 | fixed in Android 1.5 -- allowed apps to use those APIs without |
| 23 | requesting permission. As a result, apps that used those APIs broke |
| 24 | on 1.5. If you've used internal APIs in your apps, you need to update |
| 25 | your apps to stop doing so. </p> |
| 26 | |
| 27 | <p><b>Technique to Avoid, #2: Directly Manipulating Settings</b></p> |
| 28 | |
| 29 | <p>Strictly speaking this one isn't evil, since this is a change in |
| 30 | behavior that we made to Android itself. But we made it because some |
| 31 | developers were doing naughty things: a number of apps were changing |
| 32 | system settings silently without even notifying the user. For instance, |
| 33 | some apps turn on GPS without asking the user, and others might turn on |
| 34 | data roaming.</p> |
| 35 | |
| 36 | <p>As a result, applications can no longer directly |
| 37 | manipulate the values of certain system Settings, even if they |
| 38 | previously had permission to do so. For instance, apps can no longer |
| 39 | directly turn on or off GPS. These apps won't crash, but the APIs in |
| 40 | question now have no effect, and do nothing. Instead, apps will need to |
| 41 | issue an Intent to launch the appropriate Settings configuration |
| 42 | screen, so that the user can change these settings manually. For |
| 43 | details, see the android.provider.Settings.Secure class, which you can |
| 44 | find in the 1.5_pre SDK documentation (and later). Note that only |
| 45 | Settings that were moved to the Settings.Secure class are affected. |
| 46 | Other, less sensitive, settings will continue to have the same behavior |
| 47 | as in Android 1.1.</p> |
| 48 | |
| 49 | <p><b>Technique to Avoid, #3: Going Overboard with Layouts</b></p> |
| 50 | |
| 51 | <p>Due to changes in the View rendering infrastructure, unreasonably deep |
| 52 | (more than 10 or so) or broad (more than 30 total) View hierarchies in |
| 53 | layouts are now likely to cause crashes. This was always a risk for |
| 54 | excessively complex layouts, but you can think of Android 1.5 as being |
| 55 | better than 1.1 at exposing this problem. Most developers won't need to |
| 56 | worry about this, but if your app has very complicated layouts, you'll |
| 57 | need to put it on a diet. You can simplify your layouts using the more |
| 58 | advanced layout classes like FrameLayout and TableLayout.</p> |
| 59 | |
| 60 | <p><b>Technique to Avoid, #4: Bad Hardware Assumptions</b></p> |
| 61 | |
| 62 | <p>Android 1.5 includes support for soft keyboards, and there will soon be many |
| 63 | devices that run Android but do not have physical keyboards. If your |
| 64 | application assumes the presence of a physical keyboard (such as if you |
| 65 | have created a custom View that sinks keypress events) you should make |
| 66 | sure it degrades gracefully on devices that only have soft keyboards. |
| 67 | For more information on this, keep on eye on this blog as we'll be |
| 68 | posting more detailed information about handling the new soft keyboards.</p> |
| 69 | |
| 70 | <p><b>Technique to Avoid, #5: Incautious Rotations </b></p> |
| 71 | |
| 72 | <p>Devices running Android 1.5 and later can automatically rotate the screen, |
| 73 | depending on how the user orients the device. Some 1.5 devices will do |
| 74 | this by default, and on all others it can be turned on by the user. |
| 75 | This can sometimes result in unpredictable behavior from applications |
| 76 | that do their own reorientations (whether using the accelerometer, or |
| 77 | something else.) This often happens when applications assume that the |
| 78 | screen can only rotate if the physical keyboard is exposed; if the |
| 79 | device lacks a physical keyboard, these apps do not expect to be |
| 80 | reoriented, which is a coding error. Developers should be sure that |
| 81 | their applications can gracefully handle being reoriented at any time.</p> |
| 82 | |
| 83 | <p>Also, apps that use the accelerometer directly to reorient themselves |
| 84 | sometimes compete with the system doing the same thing, with odd |
| 85 | results. And finally, some apps that use the accelerometer to detect |
| 86 | things like shaking motions and that don't lock their orientation to |
| 87 | portrait or landscape, often end up flipping back and forth between |
| 88 | orientations. This can be irritating to the user. (You can lock your |
| 89 | app's orientation to portrait or landscape using the |
| 90 | <code>android:screenOrientation</code> attribute in the manifest file.)</p> |
| 91 | |