Preparing an application for distribution

Một phần của tài liệu Manning android in action 3rd (Trang 630 - 633)

Preparing an Android application for distribution is a somewhat straightforward and methodical task, though one that requires considerable attention to detail.

This section presents a list of things to consider prior to releasing your application.

It’s not meant to be an exhaustive list but rather a framework for cleaning up your application.

B.1.1 Logging

During development, it’s common to accumulate superfluous LogCat statements throughout your code. For example, you may make verbose entries to the LogCat by dumping the contents of objects to the log or recording every response from a remote server. You may even write sensitive information such as “before and after”

strings related to an encryption routine. Although these entries are helpful during the debugging of your application, they can be fatal flaws if shipped to users. Imag- ine leaving breadcrumbs to your company’s intellectual property behind in the LogCat—bad idea!

B.1.2 Debugging notifications

Your code may include the use of a Toast notification to inform you of some condi- tion or scenario, such as an unhandled branch in a switch statement or perhaps a

notification of a caught exception. This notification is helpful during the debug cycle but certainly not desirable for a released application.

B.1.3 Sample data

Your application may ship with sample data; if so, be sure that it’s properly set up for your users in an intuitive manner. Also, be sure to avoid leaving behind your own data.

For example, if you have an FTP application, don’t leave behind your own credentials in the database shipped with your application. And don’t prepopulate a form with your credit card number!

B.1.4 AndroidManifest.xml

The AndroidManifest.xml file requires careful attention before publication of your application. Let’s look at a few items you need to keep in mind:

 Remove the android:debuggable tag, or at minimum set its value to false.

 Specify appropriate values for the label and icon attributes of the application tag. Keep the text as short as possible in the label. Unless you’re an artist, get someone to assist you in the creation of attractive logo artwork.

 Specify 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. The versionName is displayed to users. The online documentation at http://developer.android.com covers these attributes in detail.

 Specify the minimum SDK level required for your application. For example, the FindEdges application from chapter 19 requires bitmap features introduced in the 2.2 version of the SDK. The SDK levels are integers that don’t correspond exactly to the commonly referenced SDK versions. The FindEdges application has the following line to specify the target and minimum SDK level:

<uses-sdk android:targetSdkVersion="8" android:minSdkVersion="8">

</uses-sdk>

The FindEdges application won’t run on a device with an older OS version due to the bitmap requirements, but your application may not be so constrained. If your application isn’t constrained, consider setting the minSdkVersion as low as possible to make the application accessible to a wide variety of devices. If your application contains a hard constraint, don’t neglect this step because properly specifying a minimum SDK level prevents users with older devices from install- ing an application that can’t run on their devices. This is better than allowing users to install your application and experience problems running the app.

B.1.5 End-user license agreement

We recommend providing your own end-user license agreement (EULA) even though most users will ignore it. You’ve written this software and likely invested heavily in its creation. You owe it to yourself and your investors to do what you can to protect your

interest in it, particularly with respect to hedging against potential liabilities your application may introduce. Obtaining experienced legal counsel is a good idea unless you plan to employ one of the commonly used open source agreements—even then, consider obtaining guidance from an experienced legal expert familiar with software licensing agreements.

It’s common to display the EULA when the application is first launched, requiring the user to positively acknowledge and agree to the terms. After the user has consented to the terms of the EULA, don’t show it again unless the user explicitly requests to view it via a menu selection. Storing a Boolean value in the SharedPreferences is an easy approach to keeping track of the user’s consent to EULA agreement. You may also con- sider showing the EULA on every upgrade in the event that your EULA is modified.

B.1.6 Testing

After you go through these steps, be sure to perform regression testing on your appli- cation on a real device prior to distribution. It’s easy to break a functioning applica- tion during this cleanup phase. The purpose of this testing is to check that all of your potentially damaging debug information has been removed. You can then move on to acceptance-style testing. Having a documented test plan is a good idea, and if possible, let someone other than the primary developer be responsible for signing off on the test plan.

Be sure to run your application under as many conditions as you can with features such as Wi-Fi, 3G, and GPS both enabled and disabled. Verify that the application degrades gracefully in the event that a required service is unavailable, such as when data service is unavailable or when roaming. It’s fine for your application to not per- form if a missing communications link is unavailable, but the application should pres- ent an easy-to-understand message to users, advising them of the situation and perhaps suggesting steps to restore connectivity.

Pay particular attention to how your application responds to being stopped and restarted. Change the screen orientation when running each Activity. Does the application behave as expected? Remember that the default behavior is for an Activity to be stopped and restarted when the screen orientation changes. You may need to return to your code and implement the Activity lifecycle methods.

B.1.7 Finishing touches

As an extra step, if your application persists data locally via a file, SharedPreferences, or a SQL database, consider providing an import/export feature. This feature can be implemented as an Activity, allowing the user to save the data out to the SD card in a readily parsable format such as CSV or XML. The import/export feature should also allow the user to restore the data to your application’s local storage. This extra feature may make application upgrades easier and more resistant to errors. Having an easy export/image mechanism via SD card also makes moving to a new device a nonevent because your users can easily bring their data with them to the new device. Your users will love you for this!

Once you’re convinced that your application is ready for release, it’s time to digi- tally sign the application in preparation for taking it to the Android Market.

Một phần của tài liệu Manning android in action 3rd (Trang 630 - 633)

Tải bản đầy đủ (PDF)

(662 trang)