1 files changed, 89 insertions, 0 deletions
diff --git a/docs/html/resources/articles/future-proofing.jd b/docs/html/resources/articles/future-proofing.jd
new file mode 100644
index 0000000..ee98186
--- /dev/null
+++ b/docs/html/resources/articles/future-proofing.jd
@@ -0,0 +1,89 @@
+page.title=Future-Proofing Your Apps
+@jd:body
+
+<p>It's important to implement your application so that it will not break as new
+versions of the Android platform are loaded onto the users device. The list
+below is based on our observations of five ways that we've seen bad apps fail.
+You can think of these as "anti-patterns" (that is, techniques to avoid) for
+Android development.</p>
+
+<p>If your application uses any of the dubious techniques below, break out 
+your IDE and duct tape, spackle, and patch up the app.</p>
+
+<p><b>Technique to Avoid, #1: Using Internal APIs</b></p>
+
+<p>Even
+though we've always strongly advised against doing so, some developers
+have chosen to use unsupported or internal APIs. For instance, many
+developers are using the internal brightness control and bluetooth
+toggle APIs that were present in 1.0 and 1.1. A bug -- which was
+fixed in Android 1.5 -- allowed apps to use those APIs without
+requesting permission. As a result, apps that used those APIs broke
+on 1.5. If you've used internal APIs in your apps, you need to update
+your apps to stop doing so. </p>
+
+<p><b>Technique to Avoid, #2: Directly Manipulating Settings</b></p>
+
+<p>Strictly speaking this one isn't evil, since this is a change in
+behavior that we made to Android itself. But we made it because some
+developers were doing naughty things: a number of apps were changing
+system settings silently without even notifying the user. For instance,
+some apps turn on GPS without asking the user, and others might turn on
+data roaming.</p>
+
+<p>As a result, applications can no longer directly
+manipulate the values of certain system Settings, even if they
+previously had permission to do so. For instance, apps can no longer
+directly turn on or off GPS. These apps won't crash, but the APIs in
+question now have no effect, and do nothing. Instead, apps will need to
+issue an Intent to launch the appropriate Settings configuration
+screen, so that the user can change these settings manually. For
+details, see the android.provider.Settings.Secure class, which you can
+find in the 1.5_pre SDK documentation (and later). Note that only
+Settings that were moved to the Settings.Secure class are affected.
+Other, less sensitive, settings will continue to have the same behavior
+as in Android 1.1.</p>
+
+<p><b>Technique to Avoid, #3: Going Overboard with Layouts</b></p>
+
+<p>Due to changes in the View rendering infrastructure, unreasonably deep
+(more than 10 or so) or broad (more than 30 total) View hierarchies in
+layouts are now likely to cause crashes. This was always a risk for
+excessively complex layouts, but you can think of Android 1.5 as being
+better than 1.1 at exposing this problem. Most developers won't need to
+worry about this, but if your app has very complicated layouts, you'll
+need to put it on a diet. You can simplify your layouts using the more
+advanced layout classes like FrameLayout and TableLayout.</p>
+
+<p><b>Technique to Avoid, #4: Bad Hardware Assumptions</b></p>
+
+<p>Android 1.5 includes support for soft keyboards, and there will soon be many
+devices that run Android but do not have physical keyboards. If your
+application assumes the presence of a physical keyboard (such as if you
+have created a custom View that sinks keypress events) you should make
+sure it degrades gracefully on devices that only have soft keyboards.
+For more information on this, keep on eye on this blog as we'll be
+posting more detailed information about handling the new soft keyboards.</p>
+
+<p><b>Technique to Avoid, #5: Incautious Rotations </b></p>
+
+<p>Devices running Android 1.5 and later can automatically rotate the screen,
+depending on how the user orients the device. Some 1.5 devices will do
+this by default, and on all others it can be turned on by the user.
+This can sometimes result in unpredictable behavior from applications
+that do their own reorientations (whether using the accelerometer, or
+something else.) This often happens when applications assume that the
+screen can only rotate if the physical keyboard is exposed; if the
+device lacks a physical keyboard, these apps do not expect to be
+reoriented, which is a coding error. Developers should be sure that
+their applications can gracefully handle being reoriented at any time.</p>
+
+<p>Also, apps that use the accelerometer directly to reorient themselves
+sometimes compete with the system doing the same thing, with odd
+results. And finally, some apps that use the accelerometer to detect
+things like shaking motions and that don't lock their orientation to
+portrait or landscape, often end up flipping back and forth between
+orientations. This can be irritating to the user. (You can lock your
+app's orientation to portrait or landscape using the
+<code>android:screenOrientation</code> attribute in the manifest file.)</p>
+