Preparing an Android app for publishing ($$)

Writing apps isn't so hard. Writing apps with high usability is another matter. Making the step from one to the other is critical, since you will have better ratings and hence make more money.

First, Wikipedia has a nice definition of usability and it forms a pretty good basis for my purpose. This is the quality of a product as seen by the end-user. I will address each point of the definition in the context of Android but you should be able to see how this applies to devices like the iPhone as well.

1. Is the user interface intuitive (self-explanatory/self-documenting)? Keep it simple. Mobile devices are powerful, but are best at a limited range of functions per app. Please don't create 20 menu items and a UI that is some complex and detailed that you can't tell what can be clicked.
2. Is it easy to perform simple operations? Again, keep it simple. The most used functions should not require going into a menu to make them work. If you followed rule one, you might not even need a menu, except for a help file.
3. Is it feasible to perform complex operations? No. Never.
4. Does the software give sensible error messages? Use Dialogs or Toast to give good user feedback (and not just for errors). Keep the users in a box so that many errors are precluded by the design of your app. When they do happen, tell the user what they can do about it (if anything). If they can't do anything about the error, keep the message simple: "Please try again later," is just fine. Don't use error codes- this is not Windows development.
5. Do widgets behave as expected? Use standard widgets, unless you are really good. There is a reason for them. Don't make things hard to use on a touchscreen. Don't make the user guess how something works.
6. Is the software well documented? Always create a Help or About file. A demo video on YouTube that your app can play is great. I just use a regular html page and load it into a WebView in a Dialog. This is simple and easy to make look good since you can use css. Just put the html and css in the assets directory of your project.
7. Is the user interface responsive or too slow? Slow apps are bad. Whenever you are doing IO or complex functions, wrap the code in a separate thread so that you can avoid the Application Not Responding message. Web sites do not always respond quickly, different phones runs at different speeds, so help your user out. Eliminate the chance of an ANR and your users will think your app runs like a dream.

Enough motherhood and apple pie. On to some real lessons learned.

Have a kid test your app. they will try all kinds of things you won't and find bugs.

You are going to need to use try/catch/finally a lot, so just get used to it. And you are going to be catching errors you have never even heard of. You will also need to catch some runtime errors (those not declared as thrown, like NullPointerException) since you can't account for everything.

Pay attention to a new feature in the Android Market- errors. Your app listings now show you weekly error reports with stack traces from some phones. This is great! Thousands of people testing your code for you and google reporting the problems. They are not too hard to fix (you usually end up catching some weird error and saying try again).

You can get errors when the handset is rotated unless you prepare your app for working that way. Here's what I put in the Application Manifest to prevent these errors. Include this in your main activity element in the manifest:

android:configChanges="orientation|keyboardHidden"

Don't forget to stop listening for updates to sensors, location services, etc. when your app is paused (unless you need these things). It is simple to turn these back on in onResume.

You may need to catch this: android.view.WindowManager.BadTokenException

It can occur when launching a new activity that wants to put something on screen but you quickly hit 'back'. Basically, you can pull the rug out from under the new activity and cause this error. I have a video app that catches this.

Avoid the ANR by putting IO (and 'expensive' code) into an inner class that extends Thread and uses a Handler to provide data back to the main UI. Other than the main activity Thread, no thread can write data to the screen. You have to use a mechanism like a Handler.

Watch out for window leaks. The fix is to call dismiss() on any Dialog objects in onDestroy(). You are overriding key life cycle events in your Activity, right?

I'm even going so far as to try an work out a scheme to watch memory usage during onCreate to ensure an app can start successfully. On older phones with less memory this can be a problem when a user is running too many apps (and Android fails to shut them down).

That's all for now. Got any more tips to share?