Posts Tagged dependency injection
Dependency Injection; Ok but how?
More Robotlegs for you guys, but this time in is more conceptual.
One thing that bugged me with Robotlegs was the use of the expression Dependency Injection. Cool word, it must mean something huge. Well if you look at it quickly; not really. If you take time to think about it, it means more.
Half of it is injection
Well, how you implement dependency injection is actually pretty simple and is something that you are doing every day (well if you program). Dependency Injection is giving, by the mean of the contructor, a method or a property, dependency (data) to an object. As Joel Hooks said it in his InsideRIA article (read it, it’s a good intro): “When you pass a variable to the constructor of a class, you are using Dependency Injection. When you set a property on a class, you are using Dependency Injection.”
Ain’t that just pleasing; I can just walk around the office and tell every one I am doing Dependency Injection.
The concept behind it
I first was reading about this on the Robotlegs best practices and I couldn’t understand anything (that’s mostly the case when I am first exposed to a design pattern, no offense to that document). After that I found Hooks article and I said to myself: “this ain’t complicated, why all the fuss”, but I wasn’t really understanding the concept (the why) behind it. It took me this article to really understand. The example is really simple and clearly expose why we should use dependency injection.
Why we should use dependency injection is mostly to create more flexible Classes. If a Class as settings that could change and that it depends on them to work, these settings should not be set inside the Class’ code but outside of it. That way every time the settings change, you don’t need to go in the Class’ code to change them. You should really read Fabien Potentier’s article about it; he does a way better job at explaining this than me. Also this presentation by Jeff More is pretty good. The more you read about it the more you’ll understand what it is.
Fine but it still feels like magic in Robotlegs
When you read the wikipedia article on Dependency Injection, at one point they list some draw backs and one of them was that “Code that uses dependency injection can seem magical to some developers” and that is exactly how I felt about it in the context of Robotlegs. Mostly because of the use of the [Inject] metatag. That is not a mechanism I was used to in AS3. I was thinking that these meta where holy blessed keywords that only Adobe could create.
Well it turns out I was wrong. Well half wrong. The [Inject] meta is used at runtime while let’s say the [Embed] metatag is used at compile time, so it is not exactly the same beast. In Robotlegs, injection is handled by the SwiftSuspenders. What it does is that for all rules you create using the method mapValue, mapClass and mapSingleton it will inspect the classes it receive. It uses the function flash.utils.describeType on the Class to do so, this will return an XML that represent that Class. In this XML, there will be tags that represent the [Inject] metatag. That is what SwiftSuspenders is looking for when parsing the class representation XML, after that it can freely do the injection (passing the values) according to the rules.
Now you could go and create your own metatags, but it seems that the compiler would remove them at compilation. If you use the source for the SwiftSuspenders instead of the SWC they tell you to add this to the compiler arguments:
-keep-as3-metadata+=Inject
-keep-as3-metadata+=PostConstruct //This is another metatag that SwiftSuspenders makes use of
This will prevent the compiler from removing the metatags from the Classes, so you could basically change these lines to make the compiler keep your newly created metatags. I have no idea why you don’t have to do this when using the SWC.
That is kinda what I wanted to cover. I’m still not fully comfortable with dependency injection but at least I have a better idea of how it works underneath. I hope you feel the same.
Some tricks when switching to Robotlegs from PureMVC
From the past posts and a couple of tweets, you all know I have been playing around with Robotlegs. Also, up until now, my framework of choice has been PureMVC, so what I want to do in this post is inform you of the little road bumps I hit when trying to learn the new framework.
Public dependency injection
The first one is really small. Robotlegs makes use of dependency injection (more on that in a later post) and to do so you have to put a meta tag [Inject] before you variable declaration. That is all good, just remember to make your variable public or else you’ll get an error. I wasn’t accustomed with the error I got so it took me some time to find out why I got it.
[Inject] public var view:Footer; //remember to make public injectable variables
Playing with models
First thing first, when creating my model I was looking to extend the Model class from the Robotlegs framework. Turns out there is no such class; models should extend the Actor class. Services also extends the Actor class.
The next gotcha was a little weird to me at first because it is different from PureMVC mindset. Robotlegs does lazy instantiation, so when you map a model using the injector.mapSingleton method the model will only be created the first time it is injected (that is how I understood it). For some models this is ok, but for others they need to be created before that. In order to do so you use injector.instantiate method and pass it the class you want to create. Here is the code for it and how you would pass data to your newly created model:
injector.mapSingleton(ApplicationModel); var appModel:ApplicationModel = injector.instantiate(ApplicationModel); appModel.init("whatever you want here");
Where do I list and handle framework events?
This is the big plus for Robotlegs, no more handling notifications but not listing them and then not figuring out why it doesn’t work. Robotlegs uses the same mechanism, in a mediator, to listen to view events than to listen to framework events which makes it easier to deal with.
So to listen to a view event I would do this:
eventMap.mapListener(view, StringEvent.HIT_ZONE_ROLL_OUT, _onRollOut, StringEvent);
and to listen to a framework event I would do this:
eventMap.mapListener(eventDispatcher, StringEvent.RESIZE, _onResize, Event);
Robotlegs basically wraps around the traditional addEventListener method and what does this give us as an additional bonus? We don’t ever have to set these listeners to weak reference because that is the way they are set by default. Oh, the joy!
Learning a new framework isn’t an easy task (at least when you don’t know any), but I found that learning Robotlegs from a PureMVC background was pretty easy. I hope you will take the time to check it out.
