I've come to realize that I'm always a bit hesitant to change. I was late to get a cell phone, late to join Facebook, late to join Twitter, and often late to look into developments within the Flash community. Lately I've been trying to change how often I tune into Flash community developments. As of late I've stumbled across two projects that struck my fancy: Robotlegs and Signals. Robotlegs is a lightweight MVCS architecture that is very focused on dependency injection. Signals is the result of Robert Penner's frustration with the Flash Player's native event system. Thus he has created an event system inspired by C# events and signals/aslots in Qt. Both looked like interesting projects so I decided to dive into them further. I'll start with robotlegs.
Having some experience with PureMVC and even having some pleasant success with it, I was quite intrigued by some claims that robotlegs is "PureMVC done right". Hmm...At any rate, I can't help but be intrigued by a claim such as this and I always enjoy looking reading about developers' often unwavering opinions about how an MVC pattern should be implemented. So after reading the docs, development forums and checking out the examples, I feel that robotlegs is a great concept and has fulfilled its development philosophy very well. It seems to me that its primary focus has been the use of dependency injection. This allows you to keep the layers of your application nicely decoupled. In my early research, I was a bit annoyed by the fact that the injection module, SwiftSuspenders, was only compatible with the mxmlc compiler. However, the latest version includes the ability to use XML to configure the injection points so I can now use it with the Flash IDE. Yes, I, and a lot of other people, still use the Flash IDE to compile applications.
My only complaint about Robotlegs is very subjective. And let me preface this with the fact that I'm not a classically trained developer (I have a degree in design, not computer science). But Robotlegs was rather difficult to get my head partially wrapped around. More specifically, dependency injection was, and still is, rather difficult for me to understand. I understand the point of it, but how its implemented in Robotlegs still seems like magic to me. And because I don't understand the dependency injection all that well, its hard for me to feel really comfortable using the framework to develop anything. In comparison, what I really like about PureMVC was that it was pretty easy to learn and the core concepts are also easy to understand (at least to me). Regardless, this is not to say that Robotlegs is any better or worse than PureMVC.
Unlike my apprehensiveness for Robotlegs, I am really excited about Robert Penner's Signals project. I stumbled across this project while researching Robotlegs. I didn't quite understand it at first, but after checking out the source and giving a go I became instantly hooked on the idea and hope I can integrate it into my future projects. Basically what Penner has done is create an event/notification system that can pass around strongly typed objects to listeners instead of the native/traditional Event object. Signals are, to put it simply, an object that represents an event. Thus a signal object has its own API for registering and unregistering listeners. Signals also gives you the ability to define the types of signals an object should possess in your interfaces. This fulfills one of my biggest wishes for interfaces: a way to define the types of events an object should have to dispatch. As of now the project seems to still be in development with Penner experimenting how to make working with native events a bit easier. I highly recommend looking into his work, but don't expect much as he's apparently in Thailand until the beginning of January.



4 Responses to “New Flash Community Developments: Robotlegs and Signals”
Hey Matt,
thanks for the overview of RL and Signals!
In my experience with both learning the concepts of automated DI and explaining them to others, the main problem seemed to stem from trying to understand more than there actually is to understand.
Automated DI solutions such as SwiftSuspenders do exactly two things:
- They store various types of request-response-mappings the application developer provides
- They inspect (again: application developer provided) objects to find injection points declared on them and set their values in accordance with the mappings
A slight complication of things is that they do these recursively. I.e., when injecting a value, they inspect it for injection points and apply the mappings to them as well.
But that’s really it.
Robotlegs adds another layer by providing a mechanism that basically allows you to say:
“when a view of this type gets added to the display list, create an instance of that type (the mediator) and perform DI on it. When the view gets removed from the display list, remove the mediator instance as well.”
Here, the slight further complication is that Robotlegs adds a temporary mapping (using Injector#mapValue) for the view instance to the injector, allowing the mediator to receive a reference to it in a strongly typed manner.
But again, (apart from additional features and other possible ways of working with Robotlegs) that’s really it.
In my view, Robotlegs doesn’t do anything particularly spectacular in and of itself. What makes it so awesome is how effortless it makes the things it does seem.
I guess that’s where the “magic” part comes in: One always expects there to be more than meets the eyes, because it seems unrealistic that so (conceptually) little does so much.
So, if you haven’t completely given up on Robotlegs and DI, feel free to join the Robotlegs mailing list and discuss anything that we’re not doing a good job of explaining right now.
cheers,
till
Really appreciate your comment, Till. I haven’t given up on Robotlegs or DI at all. Robotlegs and SwiftSuspenders are clearly great tools for developing applications in a decoupled manner, which I really wish I was doing more of. Perhaps part of my apprehension is due to the particular sector of the Flash development industry that I’m in. As mentioned, I’ve had succuss using PureMVC on projects before, but that was when I was the only developer and it ended up being more of an exercise in applying what I had learned with my own experiments. Lately I’ve been fantasizing about getting the developers I work with into working in a similar, predictable manner. My instincts tell me that it would be best to adopt a standard architecture such as Robotlegs. However, developers in the advertising/marketing sector tend to not really be into frameworks such as Robotlegs or PureMVC. So my next step is to investigate creating my own framework using Robotlegs that would be structured in a way that would perhaps be a bit easier to use for my co-developers. I’m definitely lurking the discussion forums and perhaps you’ll see me join in at some point. Until then, I’m going to experiment some more with it all and see what I can come up with.
Hi Matt,
The automatic metadata Dependency Injection might be better thought of as helper robots doing tedious repetitive work behind the scene. You could forgo the automagic help that is going on and manually inject your dependencies, but that is boring and un-fun. In that sense, the automation certainly is “magical” in that it frees us up to concentrate on the more important aspects of our systems.
I’m really looking forward to the implementations that start to crop up this year. That is the most exciting aspect of Robotlegs in my opinion. It is a “framework framework” of sorts that will allow people to implement interesting workflows.
I’ve been fiddling around with it lately and its really growing on me. Being in the industry that I’m in, I tend to compile with the Flash IDE, but I’ve started using ANT and MXMLC and really starting to like it. The magic is pretty sweet, so much so that I’m considering changing my workflow. What I’m really curious about now is modular application development so I’m looking into Till’s beta version of SwiftSuspenders that supports child injectors. The idea of a context inheriting mapping rules sounds really cool.