Archive for category Android

Thoughts on Apple vs HTC Suit

htcI have been thinking through the implications and reasons for the Apple vs HTC patent chaos. Engadget gives a great breakdown of the patents.

Many of the patents are so generic and involve ‘prior art’ that I am surprised Apple has patents for them. Take Patent #6,424,354 from 2002: Object-Oriented Event Notification System With Listener Registration Of Both Interests And Methods. Isn’t this the observer pattern from the classic 1994 Design Patterns book ?

Nevertheless, it’s likely that Apple has a least one, maybe more, valid patents. The problem is which ones? Why have Apple even included the ridiculous ones? It can only slow down the resolution process.

PC mag might have the answer.

“Just slowing down the rapid growth of Android would be a win. Just getting manufactures to think twice before rolling out Android phones would be a boon. Even a few months of legal wrangling would help Apple pad its lead.”

This equally applies to Windows Phone Series 7 (and HTC’s other Windows Mobile v6.x devices), Symbian or any other platform.

I tend to believe this is the real reason. If Apple were serious about this they would have concentrated on one or two winnable patents. As it is, there’s chaos and this can only lengthen the time over which OEMs might think twice about Android (and Windows Mobile etc). I think Apple are more interested in disrupting things than stopping competitors’ phone shipments, the latter of which they might have done much sooner has they had a more focussed legal suit.

Fragmentation in the Web Space

buzzIt’s interesting to see people complaining that they can’t get Google’s Buzz on pre-Android v2 devices. This demonstrates a point I wrote about a while ago. The deeper web browsers get into phone APIs, the more fragmentation there will be. The web is not a ‘golden bullet’ and doesn’t solve fragmentation problems. What it does do is concentrate them at one place that might be said to be an advantage in terms of development effort, cost and maintainablity.

Replacing Android Components

engadgetIn 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.

SQLite Performance

sqliteI 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

reflectionI 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.