blueBill Mobile for Android is almost ready for primetime - apart from the quality stuff. As an exception to my common practices, I didn't go with TDD since learning Android and tuning my personal coding style is already a demanding task (I also have still to learn how to run Android specific tests that, if I understand well, can be executed on the device).
Today I ran a fundamental round of refactorings trying to apply the best solution for the problem described by a specific question on the Android FAQ: "How do I pass data between Activities/Services within a single application?". For the most generic case (share any kind of Java object) there is no specific infrastructure in Android. The official FAQ answer is:
There are advantages to using a static Singleton, such as you can refer to them without casting getApplication() to an application-specific class, or going to the trouble of hanging an interface on all your Application subclasses so that your various modules can refer to that interface instead.
The predefined Application class, that can be subclassed and provide a custom context for my appplication, would introduce a dependency on Android on virtually each class of my project - no good. On the other hand, the singleton intended in strict sense has got a lot of well known troubles, as introducing unneeded couplings and making tests hard to write and maintain. A "good" context object is one that can be mocked and provide mocked services when needed. It's not hard to do, but... wait a minute. Isn't org.openide.util.Lookup exactly this kind of stuff?
It is of course! And since it's one of my common tools, it would fit nicely with the rest of my code that is already using it. Furthermore, I have got my tiny but functional dependency injection library based on the annotations of JSR-330, that perhaps could be used on Android too (to be checked against the performance warnings that people gave me when using reflection).
In the end, there's a good bunch of reasons for using Lookup in blueBill Mobile for Android, and in fact I can proudly say that I'm using it since a few hours.
Unfortunately, things weren't easy as Lookup doesn't work out-of-the-box; also when using it at its minimum capabilities (in an Android application you don't usually have modules that come and go as in a regular desktop application, so I basically don't need - at least at the moment - its dynamic capabilities).
The problems are with the Android classloaders and the .dex bytecode. I presumed I had understood all the implications, but I have to go back to the drawing board, as all my tryings ended up in ClassNotFoundExceptions or ClassCastExceptions. Furthermore, it sounds as it's impossible to load resources embedded in the application with ClassLoader.getResources() - the facility which Lookup relies on for retrieving information stored in META-INF/services. Last but not least, I would like to have also some standard Android resources, such as Context, AssetManager and SharedPreferences, to be available in the default Lookup. These classes can't be found by Lookup in the regular way, but must be forced into it in some way.