Android Java Patterns and DI

Image via Wikipedia

The debate of using Dependency Injection  in Android has always been half-assed in a way. First, some background.

On Mobile initialization is the bottleneck as opposed to Enterprise where the application is started once so we do not care about initialization times. In dependency injection there is an initialization setup penalty.

People have argued that that setup penalty means avoid DI. One counter has been use singletons-by-choice(a former NextStep pattern..yes its one of the coding patterns in iphone dev). However, the use of synchronized in such a pattern means you have the same penalty of initialization that you have if using DI and only occurs for the classes you have designated singleton-by-choice.

Does a singleton-element enum have the same initialization penalty? Its probably greater as we are warned as Android Developers not use enum in our SQLite ORM coding as its very slow.

My thinking is that since Android 2.2 onward has a JIT that we no longer have these concerns and now have a choice of DI, singleton-by-choice, singleton-element enum, and even can implement a real MVC framework. Will the start-times matter for those pre-Android 2.2non-JIT devices?  I do not think those devices will be around that much as a market percentage in the next 12 to 18 months. I think we can use l the patterns rather than quibble and claim oen pattern is the miracle worker as opposed to having all those patterns in one’s toolbox.

The only aspect where the choice becomes important is in testing and unlike several months ago we now have some mock frameworks becoming available for android such as android-mock which evens the playing field as you could use all the above patterns.

Advertisement

Why write a Guice-lib for Android

As background, yes I do have some Java enterprise coding chops where I am quite use to using IoC frameworks such as Spring. In which case you not only use Spring to make better MVC boundary definitions but also to write better unit tests via mocks etc.

Unlike Spring IoC on Android one has to use a non aop IoC such as Guice no aop library. What is missing is the Guice Modules specific to android. I could use Guice-Robo but there is not really light-weight. Not that there is anythign wrong as obviously you could load the Guice injector at the splash screen and thus avoid some of the initialization of a heavier IoC framework time by hiding that via having the user see the application splash screen.

And since we cannot use AOP anyway why mess with over-riding a class-loader? I could hand-roll my own Dependency Injection such as Bison2 does. It would at least be light enough that I could start to be able to churn out android libraries that are somewhat more flexible.

Plus, writing a dependency injection framework for Android might even be loads of fun.

Yasdic-Dependency Injection for Android

Unlike Google Guice, Yasdic handles dependency injection by String  id rather than type and is smaller than Google Guice. The code author has a good set of examples and directions.