Klok – This stuff shouldn’t be free
I recently started testing the new version of Klok. Klok is an Air app used to track your time. Version 1.5 has been out for quite a while and I didn’t work without it running. I tend to jump around my projects quite a bit and I usually have to keep track of how much time I spend on which tasks, etc. Klok has always been a great tool to let me do that. And it’s a free application! Version 1.5 is available now and 2.0 is under active development and has made some FANTASTIC improvements. This thing is, it SHOULDN’T be a free application. I really think it’s that good. I won’t go over all of the features that make it awesome cause this is a short post and I’ve got lots of actual work to do (yes, I’m logging the time I’m spending to write this blog post). There’s lots of great time keeping apps out there and I’ve used lots of them. This is the one I like the best.
Right now you can’t download the 2.0 beta unless you donate to the project. So ACT NOW while the application isn’t free. It’s totally worth it.
Now back to the work I get paid to do . . .
FlashVar manager using Swiz or RobotLegs
I use FlashVars a lot. Sometimes I need to open or launch something from my application on startup. Sometimes I just need to know some authentication credentials and that’s the way they are passed to me. Something that I have found that has made this easier for me has been to create a FlashVarManager for my projects.
FlashVars are gleaned from a LoaderInfo object and it is just a dynamic Object. (loaderInfo.properties to be exact). But you probably knew that. Being a fan of strongly typedness I usually create some getters on my manager that will fetch a specific flashVar from the .properties object and if there isn’t one give me a default. Since I always did this for Flex projects the most straightforward way to grab what I needed was through the Application instance. My manager would look something like this.
{
public class FlashVarManager
{
private static var:_instance:FlashVarManager;
private var _flashVars:Object;
public static function getInstance():FlashVarManager
{
if(!_instance)
{
_instance = new FlashVarManager();
_flashVars = Application(Application.application).loaderInfo.properties;
}
return _instance;
}
public function get flashVars():Object
{
return _flashVars;
}
public function get specificFlashVarValue():String
{
if(flashVars[‘specificValue’] != undefined)
return flashVars[‘specificValue’];
else
return "someDefaultValue";
}
}
}
Something like that.
So if ever my flashVars had to change I could just change this class. I will often perform logic in here too; sometimes create a faux “flashVar” that is based on a number of flashVars. I find it pretty handy.
But I’m trying to eliminate Singletons wherever I can. Not necessarily Singletons in the “one instance exists” sense, but more in the .getInstance() sense. RobotLegs and Swiz are really helping me out with that. But how to construct my FlashVarManager with those tools? How do you get to the loaderInfo of the app (without using the messy Application() hack)?
Read more
Signals may spell the death to my Commands as I know them
Back when I wrote my Command library I was doing a lot of calling of commands. It actually stems from the Commands/Delegates I created for the Facebook AS3 API (which have since been removed; which I think is a shame). Essentially the greatest benefit I got from my commands with the ability to do this:
function onComplete(commandInstance:CommandClass):void
{ // do stuff }
instead of this:
function onComplete(e:Event):void
{
var commandInstance:CommandClass = e.target as CommandClass;
commandInstance.removeEventListener(Event.COMPLETE, onComplete);
//NOW I can do stuff
}
That got rid of a lot of code for me and made me very happy.
Boss: Jason, how many lines of code did you write today?
Me: (proudly) Negative two-hundred-sixty-nine!
Just kidding. My boss has never asked me how many lines of code I wrote.
Read more
Swiz vs RobotLegs LIVE!
Since I began my DI framework journey I have used these two tools a lot. I’ve gone back and forth and back and forth over which I like better. Strangely, it’s usually the one I’m NOT currently using that I favor. The things I miss always stand out when I can’t use them.
Well on Wed Jan 27th I’m going to be hashing these two frameworks out live at the Phoenix Flash Platform User Group. For those unfamiliar with Dependency Injection frameworks I’ll go over the basics of how to get started with both Swiz and RobotLegs and how they are the same. It will be a “lab” session and my plan is to walk everyone who is interested through the process of building a working sample. Check back here the day of the presentation for links and resources to help us along. It MAY help to have a Facebook account and SOME familiarity with building Facebook apps with the AS3 API. I’m thinking of doing that as the example apps. What do you think?
Then I’m going to talk about how the two frameworks are different. I’m going to try very hard to be impartial. I LOVE both of these frameworks. There are a few points about them that I’m planning to go over (besides the basics of how to set them up).
- What is a Context and why does it make my hair look better?
- Will Swiz 1.0 alpha make by teeth whiter than 0.6.4?
- What if I want to process my own MetaData? Can any of this help me?
- I REALLY like to use PatternX instead of Pattern42 when dealing with my views. Can I do that?
- Commands vs Controllers on WWF SmackDown. Who’s logic will win?
- Does/should a 1.0 version really matter? (Yes, I want to talk about this one, but probably only AFTER the meeting once the booze has started flowing).
My question to you, the concerned reader is what else should I discuss? Are there any benefits or differences that you would like to see that I point out? Please leave your comments here (in a timely manner) and I will do my best to get the points into the presentation. I know there are other similar frameworks out there (Parsley is actually one I like a lot too) but these are the two I use daily and am most familiar with. They are the ones I decided to put into my toolbox so they are the ones I will talk about.
I will try to tape the presentation or at least make the slides available so maybe that can help others out there who want to get started.
Swiz vs RobotLegs
Recently I spent some time converting a medium-sized project first to Swiz and then to RobotLegs. The following is my take on the two frameworks and how I chose a winner. Right now there are definitely a lot of things I like about both frameworks, and I wish I could pick and choose the features I like best. I would call it the Peanut Butter Framework Mashup Extraordinaire.
I have considered giving Mate and Parsley a similar go but Swiz and RobotLegs were the two that definitely interested me the most so I’ve done them first. I’m pretty familiar with Cairngorm and don’t personally like it. I think I’ve read and tinkered with PureMVC enough to know that it isn’t my ball of wax either.
Keep in mind that I am refactoring an EXISTING project to use these frameworks. I am not starting a project from scratch. If I were then I might feel differently. Maybe.
What is important to me?
The most important things about a development tool, be it an IDE, a library, a repository or a framework is:
- How quickly can it help me get the job done?
- How quickly can it help me add new features?
- How quickly can it help me find and squash bugs?
- How little code can I write to get the job done?
And that’s it really. I want to write as LITTLE easily understandable code as possible and I want to be able to easily fix it and add to it.
Don’t code it ’till you need it.
For me writing code is not always a task of reuseability. If I build something for a project then it’s for THAT project. If I see that some piece of code could be helpful elsewhere then I will take the time to make that piece a project and allot it its own time. By carefully choosing what gets “bumped up” into reuseability land I am able to get the job done faster and with less effort.
With that in mind it’s important that the framework I’m using allow me to do that; write code quickly. That isn’t to say I’ll settle for spaghetti code just because it closes the job ticket faster. I know I’ll also be the one adding features to this puppy and fixing bugs. So I want it to stand the test of time. So the framework will also need to gently guide me to do that as well.
Map Commands vs Mediate Methods
One difference between Swiz and RobotLegs seems to be how they handle “triggered logic”.
Using Swiz you define instances of Controllers in your Bean Map. In those controllers you will have a number of methods that get called when an event is fired that Swiz captures (mediates).
You can use events to trigger calls to methods in RobotLegs as well but only in certain siturations (Mediator classes). It seems to instead suggest that you map Commands to Events, a technique which I was first introduced to in Cairngorm. The WAY this happens is different than Cairngorm, but the idea is roughly the same: When X happens this Command Class is created and executed.
That’s actually how the project was working before the conversion (though it was using a home-rolled solution for that).
Now I LOVE commands. I really like to use my own command library. I don’t always want to have to link a command up to an event. With my library I can play with my commands from anywhere in my code. Generally I don’t care when a command starts, finishes, etc except from where I actually called the command. This helps me keep my code-base as small as possible; needless custom events aren’t created when only one place cares about something happening. When I DO find that event information is helpful elsewhere then I can just dispatch some informative events from the command itself (using whatever the framework of the day is). With this in mind any tool that lets me to easily continue working in this manner is a win for me.
Using RobotLegs I’m able to map an Event to a Command. Awesome. I can even inject some data into it. Cool. But the Command needs to be an ICommand. And I couldn’t find ICommand in the library so AFAIK the commands actually have to extend robotlegs.Command. Not cool. I have dozens of commands already written and tied to another library. I could just change the Commands that need to be triggered by events but that sounds like a royal pain-in-the-ass and additional work == bad thing.
Using Swiz I’m not able to map the commands to events. I don’t like that. However I CAN create and execute the commands from the Controller. The Controller is mapped from the same BeanMask that the model objects are mapped in and it just contains a bunch of methods that get called when events fire (defined by MetaData). That actually gives me a little more control. I can inject the dependencies into my existing commands if I want to. But in my project all of my commands actually have constructor parameters. So I just inject properties into my Controller and using that and the properties on the dispatched events I handle the execution of the commands. It’s not incredibly elegant but it gets the job done and there isn’t much code to write or change.
Getting Events Out There
Bubbled events are cool right? Sure they are technically “expensive” and there are the rare cases of apps fighting each other over bubbled events that they throw at each other. A “Bubble Fight” I call it. Personally I’ve never witnessed one.
RobotLegs is very strict about NOT relying on the DisplayObject tree as a means to move event messaging back and forth (bubbling). Swiz lets you do just that. Bubble an event up from any attached view and any methods assigned to that event will be called. Easy-peasy. That’s another win for Swiz.
Singletons are Awesome
No their not.
Fortunately both frameworks allow you to more elegantly handle Singletons and actually ALL the data that exists in a project. Using DI (Dependency Injection) you can have objects that the framework is aware of injected right into your classes. Both use some type of MetaData to define that. [Autowire] is Swiz’s and [Inject] is RobotLegs, but it comes down to the same thing.
DI allows you to do away with the classic “Singleton” pattern. Class.getInstance() sucks. Even when you don’t care about reuseability it still sucks. As far as the injecting/tagging goes I can’t say that I’ve got a preference. But for registering these items I like Swiz better.
In RobotLegs you have a class that kind of “kick starts” things. One popular place to put the items to be injected is there. I understand, however, that you can actually do this in a number of places in a number of ways. That sounds like trouble to me.
In Swiz the accepted way of doing this is in an (M)XML document; the BeanMask. This document will define all of your “model” objects. These are the objects that can be [Autowire]d. That seems clean to me and I like it. You can have multiple Bean Masks if your project gets large, but at least you’ll know where to look for stuff.
Code from Behind vs Reach Around
I’ve got a number of views that are small. Small enough that I just put the necessary view logic in a <Script/> tag.
Sometimes that logic will grow and grow and I’ll just pull it out into it’s own class. Usually I just do a code-behind. (The MXML class extends an ActionScript class which has all the logic in it.)
Previously I had a “Global Event Dispatcher” that my views listened to. Methods were called when those events were dispatched from that “Global Event Dispatcher”.
RobotLegs doesn’t like that. I need to have a Mediator class for my logic. Then I need to bind that mediator class to the view. But not actually IN the view. Or even in the mediator (though the mediator should have a REFERENCE to the view). The binding takes places somewhere else. If I don’t play by those rules then I don’t get the benefit of mediated methods for my view.
Swiz doesn’t care. I can just stick [Mediate] on any public view method (<Script/> or code-behind) and it will work just fine. I’m not opposed to mediator classes. I think that is a fine (and cleaner) alternative to a code behind. But I don’t want to HAVE to do it that way. Unfortunately, that method DOES need to be public, which I DON’T like. I think I can get over that, but it’s essentially an event handler. It’s not something that anyone outside of that view needs to know about.
Services
Ok, I honestly didn’t put either framework through the paces when it came to working with my Services. All of my service handling is already done in a way that is already clean and I saw no need to change that at all. This wasn’t an important part of either framework for me.
Best Practice vs Get ‘er Done
Shaun Smith had a great piece about “why RobotLegs”. And I couldn’t help but get fired up about his reasons. They are good ones. But they seem like good reasons on paper, not necessarily in practice. Like I said, if I had started this project out fresh instead of trying to port it then I might feel differently. But when I look at all the code I would have to change/add using RobotLegs that shows me that there might be a lot of code that I shouldn’t have to write.
When I ported everything to Swiz it took me a couple of hours and I had things rolling. I was able to change just a portion of my application to rely on the framework. It worked alongside what I already had. But it took me the better part of some valueable sleepy-time to get RobotLegs working. And even then I still had mountains of Mediators to create before the app was truly “working”. Don’t think I’m a hater. I DO really like what RobotLegs is all about. But it’s just not for me; it doesn’t fit my workflow or my coding style.
Swiz does.
It’s late
If I’ve gotten anything wrong describing the usage of either of those frameworks then please correct me. I admit that I am a total n00b at both of these. I tried to keep it general and relatively vague; there are plenty of other resources that explain how these things actually work much better than I could.
Sleepy time.
