Cleaning up for distribution Getting an Android application cleaned up to go to distribution is straightforward.

B.3 Cleaning up for distribution Getting an Android application cleaned up to go to distribution is straightforward.

You generally need to remove any extraneous code, such as log statements, and any- thing else debug-specific, such as the android:debuggable="true" attribute, if pres- ent, in the manifest. You should also use common sense and do things like making sure that any local data stores are cleaned up and cleaned out before packaging (don’t include your test data). Along with that, you need to provide a few required manifest elements, you should test on an actual device, and you may want to add data import and export support or provide an End User License Agreement (EULA).

B.3.1 Important manifest elements: label, logo, version, SDK level Your application needs to have several key manifest elements before you consider

distribution.

You should include an appropriate label and icon using the android:label and android:icon attributes within the <application> element of the manifest. Make the icon and the label text the right size so that they are not cut off on the device or devices you are targeting. (Smaller amounts of text are better for labels, in general.)

Every application should also include the android:versionCode and android:versionName attributes in the <application> element of the manifest as well. The versionCode is an integer value that can be checked programmatically (and is typically incremented at each release), and the versionName is what is displayed to users. Android provides solid documentation on these elements as well ( http:// code.google.com/android/devel/sign-publish.html - versioning).

Along with the label, icon, and versions, it is also important to specify the android:minSdkVersion attribute. Without this attribute, the application is assumed to

be compatible with all versions of the Android SDK. If your application works with 1.0r2

A PPENDIX B Signing and installing applications on an Android device

or 1.1 but not 0.9, then you should provide this attribute (and this attribute will likely

be even more important in the future when more versions are available in the wild).

B.3.2 Test, test, then test again Once you think your application is streamlined and ready, with logo and versions and

so on, you should put it through some paces in non-debug mode on an actual device as a testing step. Here we are talking about acceptance-style testing, actually using the application to see how it performs (unit tests are also a good idea, as is the Monkey exerciser that Android provides at http://code.google.com/android/reference/ monkey.html , but those are a different level of tests that should generally come well before distribution time arrives).

Make sure to run your application under as many conditions as you can (with Wi-Fi on and off, network (GPRS, EDGE, 3G) on and off, GPS on and off, and so on), and make sure it responds as you expect (even if the response is just a context-sensitive message to users that data is not available, if that is what you expect). Pay extra atten- tion to how your application responds to being stopped and restarted; for example, if your device supports it, change the screen orientation at each activity back and forth (this stops and starts the current Activity, which may cause problems if you have not used onCreate/onStart/onPause and the other lifecycle methods appropriately).

Along with making sure your application works on an actual device in as many con- ditions as possible, you may want to consider a few additional touches.

B.3.3 An End User License Agreement Your own EULA is recommended. Everyone is familiar with these types of agreements,

from so frequently encountering them and not reading them in everyday life. Even though users often blaze past these, it is a good idea to have one to define terms and to potentially protect yourself from liabilities. (You should consult a lawyer about all legal matters, including drawing up a EULA.)

It is common to require a EULA to be shown as an Alert the first time your applica- tion is started and then not show it again on subsequent launches (you can do this with a single saved boolean as a preference). As well as showing the EULA the first time out, it is also a good idea to include a setting to allow users to get back to it and view it if they choose to.

B.3.4 Nice extra: data import and export As an extra step, if your application saves any state using any local form (files, prefer-

ences, database, and the like) you may want to implement an import/export data–type Activity. This Activity should allow the user to save the data out to the SD card (in XML format, for example) and should also allow the user to read data back in and populate the local stores. This can make application upgrades easier in some cases, and it can make switching to a new device possible without losing all local data (something your users will appreciate).

Publishing to the Market

Once you are convinced that everything is in place, data import/export included or not, you are then ready to take your wares to the Android Market.