Replacing Android Components
Posted on March 2nd, 2010
In recent news, AT&T’s Motorola Backflip is configured such that Yahoo has replaced Google as the search provider throughout the phone.
Therein lies a problem for many OEMs and network operators. It’s very difficult for them to remove something (e.g. Search, App Store, Email…) and replace it with something that’s better. The default apps and services are so good that it’s difficult to compete (and differentiate). Instead, maybe they should be thinking about adding to the platform rather than replacing components.
Android Training Videos
Posted on March 1st, 2010
Jérôme Arnaud has emailed me about his Android training videos. Chapter 12, on Intents, is available free while the others are available for $9.95.
Phone Comparison
Posted on February 26th, 2010
With all the Android phone announcements, it’s hard to keep up with the various new phone specifications. You might like to try androphones.com who are doing a great job comparing the various devices. There’s a large matrix where you can compare specifications…

SQLite Performance
Posted on February 25th, 2010
I have been doing some Android work involving medium size databases and have come across some barriers to using SQLite. With tens of thousands of records, performance degrades such that the use of the Android CursorAdapter together with a ListActivity are no longer viable.
More specifically, with just tens of thousands of records, opening the database cursor takes several seconds. Also, moving backwards using a cursor is far too slow. Digging deeper, other developers have commented on problems with Listview.setAdapter() and more specifically its call to cursor.getCount().
Anything more than 12,000 records and Android’s SQLite can’t provide the required performance for the UI performance to remain acceptable. In these cases you have to either limit the number of rows returned (via SQL) or resort to more custom ways to store your data. This goes some way to explaining why there aren’t any generic database applications on the Android Market.
Android Java Reflection
Posted on February 24th, 2010
I have recently had to use reflection in Java. It allows you to develop with the latest SDK (say 2.01 or 2.1) while still allowing code to be run on older 1.x devices. Ordinarily, running (calling) newer APIs on older phones would cause errors.
Reflection is essentially a facility to test if an API exists. If it does then you can call the API. If it doesn’t then you can degrade gracefully with an error to the user or do something else instead.
There’s a great article on the Android Developers Blog explaining how it works. It relies on a call to .class.getMethod() and catching a possible NoSuchMethodException.
Excessive use of reflection and/or not caching whether the api is there and/or using reflection repeatedly in time critical code, can cause performance problems. Also, this extra mechanism makes code less readable and, as more newer APIs become available, might make code harder to maintain.
One of the most useful places to use reflection is in testing. It allows common test harnesses to be built that can be run on both old and new code. Obviously, as it’s only test code, performance is less of an issue.

