I was privileged to present on RIA, on behalf of Douglas Reynolds Consulting to the Association of Information Technology Professionals group this evening. They provided an extremely nice venue, networking, dinner, and were very gracious hosts. The group was comprised of IT professionals, mainly from large enterprise corporations, with roles including Network Administrators, Embedded Systems Developers, Software Developers, Managers, Marketing Specialists, and more. The audience was involved, interacting with me during the presentation, which made presenting a great deal of fun. Below is my presentation deck on “What is RIA? Why Rich Internet Applications Are Good For Your Business.”

FITC Boston, 2011 is coming up quickly and I am finding that there are some sessions that I am interested in that are being presented in the same time slot. I am planning on doing some post-conference articles here on the sessions that I am attending. If you would be interested in “Teaming Up” on sharing notes, links, and other insights on sessions then be sure to add a comment below with a link to where your post-session write-ups may be found. Hopefully, the presenters will publish links to their slides as well and I will be including those when/if available.

My intended schedule looks like it will be:
Thursday October 27, 2011

• 9:00 AM – 12:30 PM – Getting social with Flex with Rob Rusher
• 1:30 PM – 5:00 PM – Flex Mobile Boot Camp with Christophe Coenraets and Holly Schinsky

Friday October 28, 2011

• 9:00 AM – 10:00 AM – Adobe Keynote with Ryan Stewart and Terry Ryan
• 10:15 AM – 11:15 AM – Refactoring: Getting Things Done, Keeping the Code Clean with Jesse Warden
• 11:30 AM – 12:30 PM – Customizing the look of Mobile Flex with Terry Ryan
• 1:30 PM – 2:30 PM – Cross Platform Mobile Applications from the Trenches with Christophe Coenraets
• 2:45 PM – 3:45 PM – Introducing Robotlegs 2.0 with Joel Hooks
• 4:00 PM – 5:00 PM – Mobile Payments with Flex with Sidney Maestre
• 5:00 PM – 5:15 PM – Closing Ceremonies

I would love to have a chance to meet you!! If we don’t hook up during the conference or at the hotel, I will be planning on stopping in at the Evening Event After Party presented by Digital Primates at The Lansdowne Pub @ 9 Lansdowne Street, Boston (www.lansdownepubboston.com)

First off, what makes a model a Robotlegs model? There is a base class in Robotlegs which is called Actor. By extending Actor, generally used in models and services in Robotlegs applications, we are able to access a property of Actor which is named eventDispatcher. EventDispatcher is shared throughout the Robotlegs framework, thusly, any events dispatched upon the eventDispatcher may be heard across the entire application. It is not required to extend Actor in a Robotlegs application. Actor exists as a helper, should you need to be able to dispatch an event and have it heard anywhere in the application. However, if you do not need to dispatch an event from a particular model, there is no obligation to extend Actor (it is recommended that you don’t in this case). Additionally, you may, of course, dispatch an event on the standard Flex framework and not create the dependency on Robotlegs. You might choose to do this if you plan to use your code in other framework-agnostic applications.
About models and services from ActionScript Developer’s Guide To Robotlegs:

They don’t listen, they only talk
Models and services are like the worst kind of dinner party guest. They have no interest in what other people have to say. All they do is send messages out to the framework–they never listen directly to their eventDispatcher property to see what other classes are saying.

Aside: If you haven’t read ActionScript Developer’s Guide To Robotlegs yet then stop right here. Over on the right you will find a link to the books site on O’Reilly Media, go get it NAO!!

Okay, the purpose of a model, in general, is to provide an API which preserves state in an application. A model is updated with state data that then may be used by other classes in your application. However, we don’t necessarily want to tightly couple our model to other classes. The best way to decouple our model is by dispatching events that may be heard by any classes that are interested in knowing that state data has changed. Enter Actor. By extending Actor in our model we now have access to the application’s framework eventDispatcher.

Here is the scenario: A service call requests some data from some remote data source (e.g. database, Webservice, HttpService, etc…). The result event of the service receives the data in the result and passes it to a factory class where it builds the resulting data into an object that we can use. The factory updates the model’s property that we are interested in and notifies the service where we can do whatever else we need to do. The important part here is that the model gets updated. We could dispatch an event from the factory or service that the model has been updated, but we really don’t know 100% from these classes that the model data is actually updated. The only place we can dispatch this event with complete certainty that the data was updated in the model is from the model itself.
Here is the model’s mutator that we will be testing:

public function set myObject ( myObject : Object ) : void
{
	this._myObject = myObject;
	eventDispatcher.dispatchEvent ( new MyEvent ( MyEvent.MODEL_UPDATED, false, false, myObject ) );
}

A benefit of accessors (getters) and mutators (setters). By using getters and setters in our model we create a public API. Additionally, by virtue of the setter method, we have a distinct method where a property gets set/updated. It is within the mutator that we can dispatch an event when we know for certain that the property has been updated. We also have public methods that we can test, such as testing state data is what it is supposed to be, and in our case for this example that an event is dispatched when state data changes.
The way I approach this is to simply check that the event dispatches when I provide the model’s property with a new value. We can add an event listener in the test whose handler method confirms that the event dispatched. Then we can assert that the result of the handler method is the same as what we expect. In this case, I increment a counter from an anonymous function if the event listener hears the event and then assertEquals. If the counter and expected value are equal, then our test passes. Otherwise, the test fails and we know there is a problem.

[Test]
public function testMyModelSetMyObject_dispatchEvent_MyEventIsDispatched():void
{
	var count:Number = 0;
	instanceModel.eventDispatcher.addEventListener(MyEvent.MODEL_UPDATED, function (event : MyEvent):Number { return count++;} );
	instanceModel.myObject =  MY_OBJECT;

	assertEquals(1,count);

}

A bit of convention explained here. The test name provides for three distinct pieces of information that will be valuable to yourself and anyone who later is maintaining your tests. A test class name provides the following information:

• The name of the method under test
• The state, or condition, which is under test
• The expected behavior of the test method

I then declare an instance counter that will be used to assert against. The instanceModel is the model that we are testing, by setting an eventListener on its eventDispatcher we can listen for the specific event for which we are interested. In this case, I want to know if the event/type, MyEvent.MODEL_UPDATED is dispatched when the myObject property of the model is updated. For ease of implementation, I use an anonymous function which takes the MyEvent type as an argument and returns a number to increment a counter and return its value. Then, I updated the model’s property, which should dispatch the event. Lastly, I assertEquals that the counter value is 1 as expected, meaning that the event dispatched, was heard in the anonymous handler method and incremented the counter.

In Test Driven Development (TDD) and Unit Testing, it is often necessary to provide the Class Under Test (CUT) with a stub of a class for which it has a dependency. For instance, this example illustrates a command class that injects a model. In order to run a test against the execute method of the CUT we need to ensure that the model and related model properties exist for the CUT in order to assert against the command’s execute method.
Mocks and Stubs are Different
First, I want to describe the difference between a Mock and a Stub as there seems to be general confusion over the slight difference that exists. According to Roy Osherove, in “The Art of Unit Testing” a Stub is defined as:

A stub is a controllable replacement for an existing dependency (or collaborator) in the system.

And a Mock is defined as:

A mock object is a fake object in the system that decides whether the unit test has passed or failed. It does so by verifying whether the object under test interacted as expected with the fake object.

The difference between a Mock and a Stub isn’t necessarily evident in simply looking at the test code, the two may look very similar. Instead, it is necessary to consider just what it is that a Mock does as opposed to a Stub. The difference can be found in how each one is used. Quite simply, a Mock gets asserted against, we are testing it to verify that the CUT interacted with the Mock as expected; a Stub is not under test and is provided simply as a means to fulfill a dependency of the CUT. So, again, a Mock is under test and a Stub is a helper class that is fulfilling a dependency of the CUT and it, itself, is not under test.

Here is a diagram that illustrates a model Stub (fake) as is used in a test that asserts against a class, a command for our purposes, for which has a dependency on the model. Notice the layer of abstraction that is created by the use of an Interface which allows us to swap the the Stub in place of the actual model class by injecting the StubModel rather than Model as would be used in production code:

Mockolate facilitates the injection of a “Mockolate” for us using some metadata to prepare and inject our Stub dependency. There are a couple of Mockolate helpers that are important to take note of as I will be using them in the example which follows. In FlexUnit there is the concept of a rule. Like [Before] and [After] provide that a method will be run before or, respectively, after each test, we can create a rule that defines a dependency injection and have it inject the additional functionality into our test. Mockolate’s [Rule] metadata is a helper that invokes FlexUnit’s [Rule] for us, thereby simplifying the implementation of injected dependency. Using MockolateRule will asynchronously prepare your dependency before each test and will wait for prepare completion prior to running each test. MockolateRule prepares the dependency prior to needing it, ensuring that it exists when used.
Then how do we get our dependency prepared? Mockolate has another metadata tag, [Mock]. Any public instance variable declared with [Mock] metadata will be automatically prepared and injected for us. This is very powerful and very sweet!!
So how do you use this stuff?
Let’s look at some code to help illustrate how we implement Mockolate Rule and Mockolate Mock and setup our test class:

public class MyCommandTest
{
	[Rule]
	public var rule:MockolateRule = new MockolateRule();

	[Mock]
	public var model:IModelInterface;

	private var instanceCommand:MyCommand;
	protected static const MODEL_OBJECT:ModelObject = new ModelObject();

	[Before]
	public function setUp():void
	{
		instanceCommand = new MyCommand();
		instanceCommand.eventDispatcher = new EventDispatcher();
		instanceCommand.event = new MyEvent ( MyEvent.DO_SOMETHING, false, false, MODEL_OBJECT );
		instanceCommand.model = model;
	}

	[After]
	public function tearDown():void
	{
		instanceCommand = null;
	}
}

In the MyCommand test class the following Mockolate and declarations are getting defined:

• Create a new Mockolate Rule
• Create a new Mockolate Mock of the model to be prepared and injected
• Create an instand of the command CUT
• Create a constant of the model object which is the dependency property we need

We need to write our setup and teardown methods which will run before and after each test:

• Using FlexUnit [Before], create setup which will run before each test in the class
• Create a new instanceCommand
• Create a new EventDispatcher as our Robotlegs Command needs it
• Create a new event as our command happens to inject this event
• Assign the model that Mockolate will have prepared for us
• Using FlexUnit [After], create a teardown method to clear our setup before the next test

At this point we are ready to write our first test. This test will check to see if the overridden public method execute actually does what it is supposed to. The execute method in this command updates the injected model with an object payload from the injected event. Although we need to test that the model does get updated, we are not testing the model here, we only need it because it is a dependency of the command, which we are testing to see that it successfully updates the model.

[Test]
public function testInstanceUpdatesModel_updatesModel_instanceCommandUpdatesModel():void
{
        stub(instanceCommand.model).getter("modelObject").returns(MODEL_OBJECT);
	instanceCommand.execute();
}

A bit of convention explained here. The test name provides for three distinct pieces of information that will be valuable to yourself and anyone who later is maintaining your tests. A test class name provides the following information:

• The name of the method under test
• The state, or condition, which is under test
• The expected behavior of the test method

Following the method naming, we see a Mockolate method which has not been previously discussed here. The Mockolate stub method allows us to define a Mockolate expectation, in other words, a dependency. Again, a Mock is under test and a Stub is a helper class that is fulfilling a dependency of the CUT and it, itself, is not under test.
In this case we need to stub the getter of the model’s “modelObject” property and check to make sure that it returns a value of type MODEL_OBJECT when the execute method is called on the command. The execute method updates the model’s modelObject property and the getter returns a MODEL_OBJECT object. If it returns a different type or null, then our test will fail. If it successfully returns a MODEL_OBJECT type, then it will pass.
Now, to write our command class so we have something to test. First, write the basic shell of the command with an empty execute method and run the test. The test will fail, perfect! Now, lets make the test pass:

public class MyCommand extends Command
{
	[Inject]
	public var model:IModelInterface;
	[Inject]
	public var event:MyEvent;

	override public function execute() : void
	{
		if ( event.myObject ) {
			model.modelObject = event.modelObject;
		}
	}
}

The MyCommand class injects the model, mapped to its interface, as well as the event which has our payload to update the model. The execute method checks to see if myObject payload exists on the event, which it will because we are providing that in our test’s setup, and then updates the model with the event modelObject. We run our test again…Pass!! Excellent! At this point we look and see if we need to refactor our command production code, if so, refactor and test again and continue this process until complete.

References:
Mockolate
FlexUnit

Here are some quick and easy solutions for trimming leading and trailing 0′s from a string in ActionScript. The examples that follow illustrate trimming leading 0′s from a string of numbers only, trimming leading 0′s from an alpha-numeric string, and trimming trailing 0′s from either a numeric or alpha-numeric string. All three are very simple to implement.
In the first problem, we need to trim the leading 0′s from a string of numbers, “00076925″ for example. This is easily accomplished using a simple parseFloat method:

private function trimLeading0sFromString() : void
{
	var numericString:String = "00076925";
	numericString = parseFloat ( numericString ).toString();
	trace ( numericString ); // 76925
}

The next problem is a bit more complex, but nonetheless simple to solve and implement. In this case we need to trim the leading 0′s from a string of alpha-numeric characters, “000076925-B72A32″. We’ll implement a simple regular expression to do the work for us here because using parseFloat would leave us with a result of “76925″:

private function trimLeading0sFromString() : void
{
	var alphaNumericString:String = "000076925-B72A32";
	var pattern:RegExp = new RegExp ( '^0+' );
	alphaNumericString = alphaNumericString.replace ( pattern,'' );
	trace ( alphaNumericString ); 	// 76925-B72A32
}

A bit about this simple regex. We are using a couple of metacharacters to help us. The caret (^) metacharacter matches the beginning of a string. We are looking for a beginning of string match, using ^0, which says – look for a match of 0 at beginning of string. Lastly, the plus (+) metacharacter matches the previous item, in this case a 0, one or many times. In this way we can look for as many leading 0′s in a string and remove them using the replace method, which simply replaces the pattern match with an empty string.

Here in our last example, our problem is that we need to remove the trailing 0′s, this expression may be used for both numeric and alpha-numeric strings. Again, in this example we’ll use a regular expression to accomplish this:

private function trimTrailing0sFromString() : void
{
	var alphaNumericString:String = "76925-B72A320000";
	var pattern:RegExp = new RegExp ( '[0]+$' );
	alphaNumericString = alphaNumericString.replace ( pattern,'' );
	trace ( alphaNumericString ); 	// 76925-B72A32
}

Note the change to the regular expression. In this example we use the metacharacter [ and ] to create a character class. We are defining that we will match any number of 0′s that we may find, matching the previous item, “+” at the end of the string “$”.

I think it is best to start off a discussion of agile development with reference to the formal origin. The Manefesto for Agile Software Development is the definition of the approach, or methodology, to agile software development. Created in 2001, by a group of 17 developers, the Agile Manefesto stands as the basis for what is defined as agile software development.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

What is the Manifesto declaring here? It is a list of principles and intentions. A public policy that states that we will value individuals and their interactions with one-another over the processes and tools that are used in project development. Individuals and their interactions are about people and organizational culture, the environment they are in when collaborating on a shared set of goals. A culture that supports individuals in a fluid structure, allowing for a sharing of roles and creativity. People are empowered in this culture, empowered to create and contribute, to provide solutions to problems and interact with anyone else on the project team. This culture is not about blame, it is about honesty and accountability where mistakes are leveraged as a tool for improvement and learning.

The Manifesto states that we will value working software over comprehensive documentation. Indeed, what is really the most important deliverable we can give the stakeholders? Working software. Additionally, the tenets of “Clean Code” provide that well written code is self-documenting. By using techniques of convention within software development, we are able to produce documentation as a byproduct of well written code. During discovery, using techniques such as user stories, we are able to capture user requirements documentation directly from the customer, which then is developed into the functionality of the project. As such, we have allowed the client to participate in, not only the definition of the project, but in the development of the project documentation. The point is that we can develop a set of documentation that provides nothing without working software. Obviously, we as developers need to understand what it is that we are going to build. In planning, we use tools to define such aspects as the functionality, the integration and flow, the user interface design, etc… These are very important to our discovery of what it is that we are building and ensuring that what we are about to build is aligned with the vision and roadmap of the project. In the end, however, it is the working software that determines success or failure of the project, not the documentation.

The next mantra of the Manifesto is customer collaboration over contract negotiation. Are you really arrogant enough to think that you know what your customer needs? Should customer collaboration be limited to a requirements document, an executive summary, change orders, project documentation, and a contract, not to mention several other standard project documents? What about interaction with the client throughout the process? Client involvement IN the project, throughout the project, has the intended effect of empowering their ownership in the project. Involving the customer in the day-to-day development ensures their accountability in the project. Customer collaboration provides that we may develop intricacies in the project that not only meet the customer needs but that are within the project scope; scope can be determined and developed in real-time with the interaction of the stakeholder. What is this collaboration thing? Collaboration is effective, ongoing, communication with the client that gives us, as developers, the means to listen and understand the client requirements. Collaboration is our opportunity to provide alternatives, point out potential problems, to guide and consult from our professional point of view how we might best achieve the client’s vision.

Lastly, the Manifesto states that we value responding to change over following a plan. We are fluid, adaptable, able to bend and redirect the project flow without causing a project failure. We are able to write code in such a way as to easily incorporate new features, change existing functionality, and provide for changing needs within the project’s lifecycle. Any plan, no matter how accurately drafted, is subject to change. “Plans in the sand”. Obviously, we must have plans in order to communicate processes. However, it is the plans themselves that must be adaptable and their authors understand that they are but a draft. Changes need to be assessed and it is important to perform impact analysis on these changes. It is important to address changes to scope and cost. The point is, that a plan be able to adapt, to communicate the effects of change, and to incorporate resulting information relevant to deliverables, risks, costs, time, and the impact on down-stream resources.

The Manifesto was created, based upon 12 self-explanatory principles as a guide to software development practice:

Principles behind the Agile Manifesto

We follow these principles:

1. Our highest priority is to satisfy the customer
   through early and continuous delivery
   of valuable software.
2. Welcome changing requirements, even late in
   development. Agile processes harness change for
   the customer’s competitive advantage.
3. Deliver working software frequently, from a
   couple of weeks to a couple of months, with a
   preference to the shorter timescale.
4. Business people and developers must work
   together daily throughout the project.
5. Build projects around motivated individuals.
   Give them the environment and support they need,
   and trust them to get the job done.
6. The most efficient and effective method of
   conveying information to and within a development
   team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
   The sponsors, developers, and users should be able
   to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence
   and good design enhances agility.
10. Simplicity–the art of maximizing the amount
    of work not done–is essential.
11. The best architectures, requirements, and designs
    emerge from self-organizing teams.
12. At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly.

Agile…I rather like that this word was coined to represent a development methodology. As defined by Merriam-Webster, I believe it is quite accurate.

1: marked by ready ability to move with quick easy grace
2: having a quick resourceful and adaptable character
…
Origin of Agile
Middle French, from Latin agilis, from agere to drive, act
…
Synonyms: graceful, featly, feline, gracile, light, light-footed (also light-foot), lightsome, lissome (also lissom), lithe, lithesome, nimble, spry

Antonyms: awkward, clumsy, gawky, graceless, klutzy, lumbering, ungainly, ungraceful

Moving quickly with easy grace, having quick resourceful and adaptable character, to drive. Not only does Agile refer to physical movement and grace, it encompasses the mind, resourcefulness, and adaptation. All of these things are important to us as developers and when incorporated into our project development methodology we have the potential to become better, provide a higher degree of professionalism and quality. Agile allows us to become more accurate, be more flexible, break down complexity into less complex and manageable chunks. Agile provides us a means to break out of linear, tightly coupled, waterfall monoliths; allowing us to create code in a communicative, craftsman-like, professional manner. Code which more readily meets our Customer’s (Stakeholder’s) requirements, code which is more manageable, testable, clean, and, well…, beautiful.

We have an obligation to be professional, just as bound to this obligation as any other professional – whether a surgeon, a CPA, or a cabinet maker. We can be artisans of our trade.

Herein we discuss User Stories, requirements elicitation, communication, feedback, prioritization, definition of scenarios, understanding. We talk about Test Driven Development and Unit Testing, having a look at “The Art of Unit Testing” by Roy Osherove. We discuss “Clean Code” concepts from Uncle Bob Martin and why this should be required reading for every developer. We cover SCRUM, its purpose and benefits in agile development. Along the way we learn more and cover additional Agile topics.

Welcome to my Agile series.

Ever do something and then wonder why you didn’t do it years ago?

I just updated my Flash Builder 4.5.ini jvm settings to increase allocated memory and found a noticeable improvement, overall, in Flash Builder. I am using the stand-alone installation on Mac, so my .ini file is found by clicking on my Adobe Flash Builder 4.5.app (launcher) file and selecting “Show Package Contents”. The Adobe Flash Builder 4.5.ini file is found in Contents/MacOS/ folder in the launcher. If you are using an Eclipse plugin installation, then it would be the same path from your Eclipse installation.

I have 6GB of RAM on my machine, these settings might be able to be tweaked for even better performance but I am really pleased with the performance increase I’m getting from this configuration:

-nl
en_US
-startup
../../../eclipse/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
../../../eclipse/plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.1.1.R36x_v20100810
--launcher.defaultAction
openFile
-showsplash
-vmargs
-Xms512m
-Xmx1024m
-XX:MaxPermSize=512m
-XX:PermSize=128m
-Xdock:name=Flash Builder
-Xdock:icon=../Resources/fb_app.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Declipse.product=com.adobe.flexbuilder.standalone.producte36
-Declipse.application=com.adobe.flexbuilder.standalone.FlashBuilderApplication

Basically, I simply doubled all memory settings. Improvements were immediate and noticeable upon restart.

_HTH

References:
Adobe Knowledge Base
PolyGeek

I’m thinking about getting an Android tablet for Dev, as well as regular tablet use. There are 3 that I am considering: Motorolla Xoom, Samsung Galaxy Tab, and the Acer Iconia A500. All 3 are 10.1″. All specs are pretty much the same except for the following:

Samsung has the greatest resolution on it’s rear-facing camera (8 megapixels, compared to 5 on the other 2) – +1
Samsung records in 1080p, compared to 720 on the others +1
Samsung has no SD card (boo!) – Xoom’s currently doesn’t work right (Galaxy -2, Xoom -1)
Samsung has no hdmi output -1
Acer has a USB interface, Xoom has a microUSB interface, Samsung has a proprietary interface to USB (acer +1, xoom +1)

Final Score:
Samsung -1
Xoom +1
Acer +1

Oh, cost:
Acer ~ $450
Galaxy Tab ~ $599
Xoom ~ $499

What do you think of this comparison and weighting of scores?
Feel free to add comment about additional considerations or tablets you feel should be included.

I like to setup a basic skeleton project to use as a template for new projects. Given that I’ve been developing with Robotlegs for the past couple months, and I’m getting more and more comfortable with it, I decided to go ahead and flush out a skeleton project with FlexUnit for TDD and UnitTesting.
Another great thing about skeleton projects is that they illustrate how a project can be setup in as bare form as possible. It is always difficult to get into docs and get started quickly when trying to figure out how to simply get a project setup. So for beginners in Robotlegs, I hope this gives you a head start on sorting through the framework.

Here is the quick rundown on Robotlegs with links to docs:
Be sure to checkout the Robotlegs Best Practices wiki, and…
Robotlegs API Documentation
.
Context
Every Robotlegs project has a context, which is the central application communication mechanism.

Controllers
Controllers are comprised of command objects which perform something specific in the application.

Commands
Commands are stateless objects that do specific work.

Model
Models are stateful objects which provide a means to store application state.

Views and Mediators
Views and Mediators are the user interface to your application and the pattern of handling interaction with the views in the application. A mediator decouples the view from the application by handling event listening and dispatching view and framework events.

Dependency Injection
Robotlegs uses the SwiftSuspenders dependency injection library to provide IoC in the framework. Dependency Injection is basically providing an object with its properties. For instance, you could inject an event into your command so that you can access that event’s properties and values.

The skeleton project provides a template that can be modified and tailored to meet your needs, changing and improving over time, so that you can quickly ramp up new projects. This project provides a basic application directory structure and Robotlegs framework architecture, along with implemented FlexUnit test suite and test classes. It is completely setup for Test Driven Development and continual Unit Testing as you develop your application. The skeleton is setup for Flash Builder 4.5 Premium, for use with FlexUnit. If you find errors in your FlexUnitApplication and/or FlexUnitCompilerApplication files upon creating your project, rebuild those files in the FlexUnit view by clicking on its refresh button.

Below, for convenience, I have provided a running .swf of the application, being that it is just a skeleton it doesn’t do anything yet other than launch an alert. You can right click on the .swf to view its source. I will be maintaining the skeleton based upon feedback and ideas about what should be included.

You can download the .fxp here Robotlegs Skeleton With TDD
Downloaded 104 times

Thanks to @seantheflexguy for project review and ideas.
Reference: Strategy game. Test setup is largely influenced by Stray