As we've seen in the previous chapters there are differences between devices in various areas. Before you publish your application, make sure it runs well on a couple of common devices and Android versions. Sadly, there's no easy way to do that at this point. I was lucky enough to get a couple of phones, covering different device classes and generations. Depending on your budget, though, that might not be an option. You might have to rely on the emulator (but not too much, as it is indeed unreliable) or preferably on a couple of friends to help you out there.
Another way to test your application is to put a beta versionon the Android Market. You can clearly mark your application as beta in its title so that users know what to expect. Some users will gladly ignore all warnings and still complain about the quality of your potentially unfinished application. That's just how life is, and you have to learn to deal with negative and maybe unjustified comments. Remember, though, your users are king. Don't get angry at them but try to figure out how to improve your application instead.
Here's my current setup for testing applications, which has served me well:
Samsung Galaxy Leo/I5801, 320x240 pixel screen
HTC Hero with Android 1.5, 480x320 pixel screen
Motorola Milestone/Droid with Android 2.1, 854x480 pixel screen
■ HTC Desire HD with Android 2.2, 800x480 pixel screen
■ Nexus One with Android 2.3, 800x480 pixel screen
As you can see, I cover quite a range of screen sizes/resolutions and device generations. If you look for outside testers, make sure you get coverage of most of the device generations outlined here. Newer devices like the Samsung Galaxy S or Motorola Atrix should, of course, also be on your list, but less for performance testing than for compatibility testing.
Another domain of devices that is just starting to gain traction is Android tablets. At the time of writing this book the Samsung Galaxy Tab was pretty much the only tablet on the market, and the Android Xoom was just announced. With tablets you have to prepare for a larger screen size and resolution, of course. The techniques we discussed should scale very well. If you want to get fancy, you can even try to use the methods that take screen density and physical size into account, as we discussed in Chapter 5.
Finally, you have to live with the fact that you can't test your application on all devices out there. You are likely to receive error reports that are inexplicable and might well stem from the fact that a user has a custom ROM running that doesn't behave as expected. In any case, don't panic; this is to be expected to some extent. If it goes overboard, though, you'll have to try to come up with a scheme to battle it. Luckily the Android Market helps us out in that regard. We'll see how that works in a bit.
NOTE Apart from the Android Market's error reporting there's another nice solution, called Acra, which is an open source library specifically designed to report crashes of your Android application. It's available at http://code.goog1e.com/p/acra/ and very easy to use. Just follow the guide on the Google Code page to integrate it in your application.
Was this article helpful?