The hunt for the J2ME-friendly IoC container is on!

views:

522

answers:

+3 Q:

The hunt for the J2ME-friendly IoC container is on!

Hi all,

I'm in the beginning phases of a Blackberry/J2ME project -- and along with other limitations that come with this wonderful platform, the lack of support for reflection and 1.3 language level mean that the vast majority of existing IoC containers are unusable. (Google has Guice for Android with no AOP, but even that requires support for annotations).

So the space of IoC containers on J2ME is pretty limited. The one framework that has caught my attention is called Signal Framework, and it looks pretty promising. It tries to stay conceptually close to Spring Framework's IoC, implementing a small subset of its functionality, and does so without relying on bytecode-modification or causing runtime xml parsing. Instead, it processes configuration XMLs at build-time to generate java code which implements this IoC functionality.

Generally speaking, code generation at build time seems like a very wise approach for mobile applications -- and if my app has to do less XML parsing on user's device, that's great too!

So, what have your experiences been with implementing IoC on J2ME/CLDC, and how were you able to extinguish that bitter taste in your mouth?

+2 A:

In J2ME you need to reduce the number of classes you use as much as possible to reduce the size of jar files. This leads to many design compromises not least of which is flexibility.

It is not easy to adjust to J2ME development when you have to throw must of what you hae learnt (and come to value highly) about OO out the window. The truth is if you want apps that can run on a large range of phones you need to be very sensitive to the constraints of the devices.

As such I do not think an IoC framework will match many people's needs for J2ME development.

Grouchal 2009-06-24 19:35:19

Danke shön for your insight, Grouchal :) I agree with your thoughts on having to put aside some app design preferences on J2ME. The reason why I think I can afford to use an IoC framework, however, is that the app I'm developing is going to target the more powerful CLDC-based devices like recent Blackberries and J2ME on S60 (as well as Android, with some mods).

Paul Milovanov 2009-06-25 22:04:38

The idea behind limitations imposed by CLDC 1.0 was fantastic at the time when CLDC 1.0 was being conceived; today, however, it seems that most devices of interest are much more powerful and have more storage. The question of whether we can transfer good development practices like the use of IoC to mobile java development is therefore pretty natural.And, like I said, if this can be done by build-time code generation instead of during runtime, and it achieves a dramatic improvement in the clarity of organization of code -- why not use it?

Paul Milovanov 2009-06-25 22:07:19

Signal Framework it is.

Update: unfortunately, Signal is very undercooked right now, so I'm going with Israfil IOC with custom additions.

Paul Milovanov 2009-07-14 19:56:02

+1 A:

You might be interested in checking out FallME. Even though I haven't used it personally, it seems like a no non-sense framework built specifically for the J2ME platform.

paracycle 2009-07-27 08:34:33

thanks paracycle, I'll look into it!

Paul Milovanov 2009-07-27 21:38:05

+1 A:

I came across Spring ME during a Dutch JUG conference (have no experience with it whatsoever).

R. Kettelerij 2009-07-27 21:54:14

We used Spring ME at TomTom. It worked out pretty well.

Wilfred Springer 2009-08-13 18:54:04

ansaurus

tags:

views:

answers:

The hunt for the J2ME-friendly IoC container is on!

related questions