I’ve just released an Android app on the market, it is a location utility app called Address Location Finder.

Address Location Finder

Basically it allows you to locate an address – then pass that location onto other apps or mapping utility websites.

You can just enter the address to search for, or get it from your contact list or get it from a SMS (if the message contains only the address).

The app then uses the Google geocoding services to find the location for that address. Once it has the location then you can do various things with it:

• view the location with the simple built-in map, for simple navigation
• pass the location to other mobile apps, such as StreetView, Google Maps, etc
• pass the location to some useful mapping utility websites, these include sites that:

• showing a radius around address location
• find another location with a particular distance and bearing from the address location

This is the free version, and while this first release is a BETA all the basic functionality should work.

If you have a chance to try it, please let me know what you think about it or if you come across any problems with the app.

I’m currently developing an Android app and have been reading up on Android testing. Here are some tips that I’ve come across and found useful, as well as some ideas of my own.

Emulator vs Device

Testing on a real device is generally recommended over using the Android emulator for various reasons:

• You should test as close as possible to the user environment.
• A device is a more realistic environment for acceptance testing.
• The emulator is slow, and often buggy. I’ve encountered issues with various versions of the emulator, when trying to test things like orientation changes, location services, etc.

While I agree that you should do most of your testing on real devices, sometimes testing on the emulator can be a useful addition.

Advantages of Testing on the Emulator

1. You can increase memory and heap for an AVD (Android Virtual Device).

This may be necessary if you have a lot of tests to run together or have complicated tests (e.g. if using recursion). Of course devices are limited to how much memory they have installed and could run out of memory when running test suites.

2. For testing with particular configurations, e.g system settings such as GPS.

You can setup an AVD with GPS on and another exactly the same except with GPS off (once configured, they would be saved as snapshots). Then you could have annotations in the test cases for which tests to run in which environment.

If you were testing this with a device, then you would need to remember to configure the settings before the tests are run. This may be alright for manual testing, but a major hassle for automated testing (for instance, if you’re using Continuous Integration practices).

In fact, a tool like the Jenkins Android Emulator plugin could be configured to start the appropriate AVD in the emulator when required (or even create one based on a set of configurations).

3. The emulator is free.

Of course using the emulator is cheaper than buying a truckload of devices, especially with so many Android version and screen sizes out there. You can use the emulator to fill in the gaps for whichever configurations you don’t have devices for (is it worth buying separate devices to test Android version 2.3 vs 2.33, for instance).

Testing on a Rooted Device

Most advice about using rooted devices for testing seems to be, DON’T. Most of the time this is good advice, as you want your test environment to be as close to what your customers are using as much as possible.

However you might find it sometimes useful to run some of your tests on a rooted device. In particular, being able to have read and write access to otherwise secure directories can be useful.

Some examples of this would be:

• to copy a test database onto the device
• copying junit report files off the device for archiving
• doing a full backup of various device configurations, to restore later for testing

Some more tips later in part 2 of this article.