11:42:43 am on November 8, 2010 |

Let me start by clarifying: I like… no, I love the Android API. It’s an elegant, user friendly and very powerful way of developing apps.

That said, no system is perfect, and there are few niggling issues with Android:

Non-POJO Components: All the main Android components (Activities, Views, etc.) are inherited from concrete classes, and have lots of dependencies on other concrete implementations like the Context class. Not only does this go against the “program to an interface” principal, it also makes TDD and dependency injection (DI) trickier. No Dependency Management: It’s tricky to re-use Jar files in Android, and it would’ve been nice if the Android platform had been built with something like OSGi in mind, to increase binary re-use and reduce downloads, and generally make developer’s lives easier. Rigid Tools: While the Android Development Tools (ADT) make Android development easy, they are rigid. The generated source folders can’t be moved from their default locations. For example, if you wanted to move them under the Maven target folder, you can’t. Not only that, but my work with the Maven Integration with Android Development Tools project demonstrates that the ADT isn’t really built for extensibility, with no exported packages.

That said, there is some work going on to resolve the above. Roboguice is a DI framework written specifically for Android which addresses issue 1 above.

There is also ongoing work to get the Apache Felix OSGI implementation, working on Android [PDF]. Although, this is hampered by Android’s application security.

Finally, the Maven Integration with Android Development Tools project will hopefully relieve some of the rigidity of the ADT. I’m also hoping to submit some patches to the Google’s ADT project to export some of the more useful, internal classes to make writing extensions on top of the ADT easier.