Android Java Patterns and DI

Posted: September 5, 2010 in Android
Tags: , , , ,
Screenshot of Android Emulator for SDK version...
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.

Enhanced by Zemanta
Advertisements
Comments
  1. ktoso says:

    Nice to hear such an opinion. I’ve migrated my simple android app from an “hey there’s thjis singleton” onto sweet Guice DI and am very happy that I did it. It’s a very simple app, but I didn’t notice any delay during startup compared to the singleton.getInstance() version. Anyways, here’s a short intro into Dependency Injection using RoboGuice on android I’ve posted yesterday: http://www.blog.project13.pl/index.php/fun/786/android-the-right-way-dependency-injection/

  2. When I started coding with Android I really wanted to use DI, but then I focused more on developing things that users were asking. Reasonably by the end of the month I could deliver most of they want, and then refocus on refactoring the application.

    Indeed, I believe that the DI “slowness” with Android is mostly a non-problem. I understand Google advicing about it, as a general rule, but it depends on the context. For instance, my app stores a small amount of data by means of Java serialization. It’s not the definitive way to do that, but it works while I’m working on something better. There are not big penalties at start up and you bet there’s much more reflection there than in the possibly 10-20 injected references I could use.

    In the past I’ve even thought of alternative approaches (such as writing a Lombok plugin that translates DI annotations in code during compiling time, thus requiring no reflection), but in the end regular reflection-based DI is probably ok in my case.

    Of course, I’m still thinking with retro-compatibility in mind. As you said, with JIT this could be really no more a problem.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s