More than a few reasons to go to FiTC San Francisco
I'm extremely excited about FiTC San Francisco. These guys know how to put on a show.
What a line-up. Yugo Nakamura, Kevin Lynch, Mario Klingemann, Ralph Hauwert, Grant Skinner... The list is huge, and filled with top notch presenters. I'm a bit sad, as I am presenting at the same time as Keith Peters. His "Programming Art" talk sounds awesome. It is going to be three full days jam-packed with awesome.
I'm going to be giving a talk on Robotlegs at the event.
There is still time to get the early bird tickets, and FiTC is offering a 10% discount if you use the code "joelhooks" - really hope to see you there.
Do we really need THAT much metadata in AS3? Not with Robotlegs…
There was a time in the push for a Robotlegs 1.0 that a nometa implementation existed. Robert Penner still uses it, if I'm not mistaken. It doesn't have as much convenience as the regular meta-loving MVCS implementation, meaning it doesn't inject a bunch of classes into the MVCS base classes. Is that bad? Not really. I find myself rarely using the injected classes anyway. At the time I pushed back on the nometa implementation and its inclusion in the core. I still think that is proper, because it would just tend to cloud the implementation and make it more difficult to document and support, both of these being key pillars in making Robotlegs a successful project that people will actually use. The concept of using as little metadata as possible in my applications is very appealing.
Modular Robotlegs
WTF is a Modular?
Modular programming is a versatile technique for separating an application into smaller parts. Each module is effectively an application and can be developed independently from one another. In a typical modular application you will have a Shell that is loaded initially. The Shell will manage the loading of modules and displaying their contents. Flex modules can be visual components that extend the Module class, but this is certainly not the extent of what can be considered a module.
Robotlegs is well suited for modular application development. Each Context is encapsulated and provides its own internal method for communication. A barrier to writing modular applications thus far with Robotlegs is that while these Context objects can exist in abundance in an application, they aren't very useful from a modular standpoint unless they can communicate with one another. As with many things within the Robotlegs eco-system, this is best accomplished through the development of a utility that can be used in conjunction with the core framework to provide the specific functionality that we are looking for. There has been some good work done in this area, but with Robotlegs 1.1 and more specifically the 1.5 release of the default Dependency Injection provider SwiftSuspenders, we have been equipped with better tools to accomplish modular contexts in a Robotlegs application in a clean effective manner.
IntelliJ Idea Flex and Actionscript 3 Workflow: [Part 1] Creating a Flex Project
I've been using IntelliJ Idea 9 quite a bit in both production and personal work lately. It is a great IDE, with lots of useful features. This is going to be a series of short screencasts that highlight the workflow in Idea for Flex/Actionscript development. The first is a quick introduction and how to set up a Flex project. If you have any questions or requests for future videos in the series please feel free to leave them in the comments.
direct link to the video (42mb QT)
Resources
IntelliJ IDEA EAP Download Page
Jesse Freeman's IDEA Workflow series on InsideRIA
Robotlegs, AS3-Signals and the SignalCommandMap Example
Robotlegs and AS3-Signals play really well together. Both apply solid object-oriented principles to accomplish their respective goals. Signals is extremely well suited for automated Dependency Injection. By combining Signals and Robotlegs you are able to eliminate the use of Flash Events in the framework layer of your application. Eliminating Events means eliminating the ambiguity that can accompany Events and their String registry based approach to the Observer pattern. Signals provides a strongly-typed object-oriented approach to this same pattern.
With the standard Robotlegs MVCS implementation you leverage the events provided by Actionscript 3 to communicate amongst the various actors of an application. From models and services dispatching notifications of their actions to triggering commands, events are a core piece of the implementation. To facilitate the use of Signals within MVCS it was necessary to create an extension to allow for Signals to be registered as Command triggers. This need spawned the SignalCommandMap utility.
The SignalCommandMap extends the normal MVCS context and creates a SignalContext. The SignalContext instantiates and provides access to the SignalCommandMap alongside the other maps that are standard to Robotlegs. The SignalCommandMap allows you to map Signal classes and instances to commands that will be executed when the Signal dispatch() method is called. The value objects that are passed in the dispatch are then injected into the command alongside any other mapped injections you have created.
Let's take a look at a simple example that makes use of the SignalCommandMap and discuss some of the underlying code to see how it works:
Robotlegs on RIA Radio with Shaun Smith and Myself
Shaun on I were on episode 6 of RIA Radio to talk about Robotlegs. Check it out!Robotlegs Image Gallery Example using AS3-Signals and the Presentation Model
Jason Crist posted a thought provoking request for his upcoming presentation comparing Robotlegs and Swiz. He's got a clever knack for stirring the framework ant pile and getting developers eyes off their IDEs long enough to discuss their passions. In this case the developers include Ben Clinkinbeard, Shaun Smith, Jesse Warden and myself.
These conversations are always good natured. While we work on (or use) "competing" frameworks there is always a sense of mutual respect. We like our tools but have obvious inclinations towards the projects that we've invested our hearts and souls into.
Ben Clinkinbeard has pointed out (several times!) that Robotlegs is all about extending the MVCS classes. My stock answer is that there is a clear separation between the framework and the concrete MVCS implementation. To paraphrase Ben, "Well show it to me then!"
All of the "official" Robotlegs examples are making use of the MVCS implementation. Why? Because it is solid, recognizable, and fairly easy to get one's head around. It provides a common ground for developers and a set architectural structure which is a huge advantage in any team environment. It is important to make the distinction between the framework and the MVCS implementation. What does that even mean? At the core, Robotlegs is a modular set of tools to provide a convenient mechanism for wiring applications. Robotlegs is not doing class reflection. Robotlegs is not an automated dependency injection solution. Robotlegs is an adapter to a dependency injection solution,by default the lightweight SwiftSuspenders library. Through a set of tools, namely the MediatorMap, CommandMap, ViewMap, and the injection adapter Robotlegs provides a robust starting place to begin coding your application.
The MVCS implementation is a set of base classes loosely modeled on PureMVC. At the heart of the implementation is the Context. The Context creates instances of the various mapping classes, the injection adapter, and gives the developer a centralized IEventDispatcher that can be used for messaging between application tiers.. The other three classes, Actor, Mediator, and Command, reduce boiler plate and provide convenient access to injected dependencies typically used in the the MVCS tiers.
What if you hate PureMVC, don't want to extend any framework classes, or generally just want to work in a different way outside of a prescribed MVCS architecture?
No problem.
Here's the deal. Robotlegs, the framework, is a set of interfaces. You can effectively do whatever you want with these interfaces. You can make use of the base concrete implementations of the core interfaces, use a class from the MVCS implementation, implement your own concrete classes based on the framework core, bring in other libraries or any combination you can think of. In terms of a framework, Robotlegs can be whatever you want/need it to be.
Man Joel, that was a long intro. Where's the freaking code??!?
Continuous Scrolling Thumbnail Component for Flex
This post continues to be the most popular on this space after a year and a half. I've never been particularly fond of the implmenetation. Tightly coupled to very specific data sets and not really anything like a Flex component. It is setup more like an application (because it was pulled out of an application and generalized).
I've finally found the opportunity to rewrite the continuous scrolling thumbnail view portion of the slideshow and I am much happier with the results. Now, instead of resembling an application it is structured like a standard Flex 3 List based component. You supply it with a dataProvider and an itemRenderer (IListItemRenderer) and it acts as you would expect it to.
This approach is much nicer, as the data is cleanly decoupled from the component implementation and it opens up the doors for reuse.
The code is available on Github. If you have any suggestions or would like to add to the component, fork it and let me know!
Robotlegs MVCS: Walkthrough of an AIR Twitter Client
Here is the "completed" project on Github.
This is a roughly 25 minute walkthrough of wiring together a Twitter client using the Robotlegs AS3 Micro-Architecture MVCS implementation. It covers setting up the context, using commands, mediating composite view component, granular view component mediation, and retrieving data from a service.
Apologies in advance for the ambient noise. 4 kids, 2 dogs, and a busy wife does not make the perfect sound booth 
I am considering expanding on this example and creating a start to finish video series creating a full Twitter client with Robotlegs. This would cover the actual component building, wiring everything together, working with data models (local storage, etc), and refining the application to use the advanced features available with the Twitter API using TDD the whole time for development. Is this something that you'd be interested in?
