Skip to main content

Dependency Injection?

8 replies [Last post]
cliff76
Offline
Joined: 2006-01-03

Hello all,

I'm new to JavaME and wondering what solutions are currently available for dependency injection. We started a project at my company where T.D.D. was used through and through. I hacked together a band-aid implementation for D.I. but I'm curious to find out how others address the need if at all. I'm looking for a tool or framework that will allow me to wire my application together much like Springframework does for JRE based apps. Is there anything at all in the ME space?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
dserodio
Offline
Joined: 2004-02-10

DI != Spring, it can be much simpler than that.

I've never done anything in ME, but I think the PicoContainer "philosophy" fits ME better: http://picocontainer.codehaus.org/

cliff76
Offline
Joined: 2006-01-03

Yes that compiles.

DI != Spring

This also compiles correctly:
Spring.contains(DI)

I could reference pico instead of Spring when I discuss but I'm not sure what you're trying to tell me. Basically what I have is pure dependency injection managed by a build time XSLT transform. Are you saying my solution can be simpler or that I shouldn't be looking for an entire Springframework for Mobile? I can agree with either point but I'd want more detail on the former.

terrencebarr
Offline
Joined: 2004-03-04

I am not an expert on this topic but I was contacted by Christopher Judd of www.juddsolutions.com a while back. He has developed a Spring framework for Java ME and was interested in working with the open source community. I haven't heard about the project lately but I pinged him on the topic. I might have more on this shortly.

-- Terrence

cliff76
Offline
Joined: 2006-01-03

Sounds good! Keep me posted.

sfitzjava
Offline
Joined: 2003-06-15

Hi Cliff76,

Read your blog, and well there are some points that I would like to correct you on. While ME does not have a classloader, you can use Class.forName(), and it is very useful. As for T.D.D (Test Driven Design), I don't see where there are large hurdles. Most of the ME code (minus UI) can be run on the desktop and tested, and with some of the ME2SE projects you can even run the UIs. I think CqME is a testing framework for ME, and can be found at cqme.dev.java.net

I have not heard of a spring-like framework for ME, however I have two project at Java.net that might help address the items you mentioned. The first (MicroBus) is an EDA (Event Driven Architecture)-ish component that might give you some ideas for your decoupling needs.
The second is the MDO project that helps decompose objects into their parts for persistence or transmission over the wire to backend servers. (the most recent code MDO2 is more up-to-date).

But to your point that ME is not a cake walk, I will agree, and that early optimization is bad, I would agree more. But heavy OOD is really bad for ME... and I would contend anywhere. ;)
....Bet I get flamed for that...

Regards,
-Shawn

cliff76
Offline
Joined: 2006-01-03

Thanx for the reply Shawn. I'm going to look into those two project you mentioned. In the interim I'm trying to find out how to address assembling or wiring the ap after it's been decomposed. In other words, I have a completely decoupled architecture, right? None of the components instantiate any dependencies. Something has to put the thing together doesn't it? I could write a java class that just pulled everything together but then when certain components need changing I'd have to edit this class and put in the new dependency wouldn't I? I guess what I'm really asking is if there is really any need for my Fallframework or if I'm over-complicating something simple? Is there another way to pull the dependency details out of code and into the build? What I'm ultimately trying to get is a way to build for different deployment targets (i.e. emulator, Blackberry, Nokia, Motorola, etc.) by suppying a profile sheet. I think of a profile sheet almost as a list of ingredients (or actual concrete instances) that go into the finished product.

I will buy the fact that heavy OOD is bad for ME and that's really not my goal. I'm only after a good and completely decoupled design that may or may not follow all of the rules of OOD. Am I making any sense or do I sound more confusing and ambiguous than anything? Thanx again for responding.

Cliff

sfitzjava
Offline
Joined: 2003-06-15

Cliff,

Your needs of a profile sheet are spot on. Having some part of code that defines the special parts of a device, and then built into a finished (I'm inferring) device specific deployment sounds similar to how I'm looking at the problem too.

I'm working on something like this but I'm looking to a very basic solution using interfaces, class loading by name, and a build script that adjusts to pull the correct device profile. While I can't go into deep details (NDA with employer), I can address the basic concept.

public interface Profile {
public String getStrInfo(String _key);
}

public class BBProfile implements Profile {
private Properties bbData = new Properties();
static
{
bbData.put("stuff","BBProfile stuff");
};
public String getStrInfo(String _key) { return (String) bbData.get(_key); }
}
public class NokiaProfile implements Profile {
private Properties nkData = new Properties();
static
{
nkData.put("stuff","NokiaProfile stuff");
};
public String getStrInfo(String _key) { return (String) nkData.get(_key); }
}

public class MyMidlet {

private String profClass = (String)System.getProperty("profClass");
private Profile p = (Profile)Class.forName(profClass).newInstance();
}

So here the property value "profClass" would be in the descriptor file, and set to whatever the build was for BB or Nokia devices, then the build would only need to include from the profile package things that start with a class name of BB or Nokia. So in the end you only have the profile class that is correct for the device in the jar, and loaded. But when you pull the information from the profile it is only that which was set in the static section of the device specific profile.

Who knows if you are making it more complicated, but I feel you are thinking about a problem that most folks look at and say "device fragmentation sucks, why can't they make all devices the same" and then they walk away. Well innovation and competition is why there is fragmentation, and I would say innovation is great. Sure fragmentation sucks, but, as we are, do something about it.

So keep on with your project, you may solve this or other problems in a unique way. Other may not like your way, and so they come up with another, maybe even better solution...cool now we have 2 solutions. Again Innovation is good. :) BTW: I think Jpolish has some type of reflection code generation at compile time thing...but I don't like solutions that require additional preprocessors. Feels too much like 'C', and in the end messes up the code so that you have to have some elaborate build environment instead of being able to use your favorite IDE or command line tools. But then again it's just another way of looking at the problem. To each their own.

Best regards,
-Shawn

cliff76
Offline
Joined: 2006-01-03

I wanted to include a little more detail on what I'm looking for. See my weblog for details on my experimental project that attempts to bring the Springframework to JavaME: http://codeforfun.wordpress.com/2007/10/07/fallframework-for-mobile/