Having read through similar discussions on the forums however, I’m not convinced MATE purists will like/agree with this post, but I feel most confortable with property getter/setter properties and it has always been a common method in ActionScript.

Mate 0.8.6 included a new tag called PropertySetter and my eyes lit-up as soon as I read it on the change log. The PropertySetter tag (there’s no documentation for this tag yet) allows you to communicate with Managers by directly assigning values to a property, and using getter/setter property functions to check, manipulate and fire off other events as necessary.

Before the PropertySetter tag my EventMap used to communicate with Managers like this:

<EventHandlers type="{PreferencesEvent.BREAK_LENGTH}" debug="false">
<MethodInvoker generator="{ApplicationManager}" method="setBreakLength" arguments="{event.value}" /></pre>
</EventHandlers> 

and the related methods within my Managers used to look like this:

private var _breakLength : int = 0;

[Bindable(event="breakLengthChanged")]
public function get breakLength () : int
{
	return _breakLength;
}

public function setBreakLength (value : int) : void
{
	breakLength = value;
}

notice the use of a proper property getter function, but no proper property setter function – that has always felt so awkward to me. With the PropertySetter tag, I can now set a property in my Manager from my EventMap like this:

<EventHandlers type="{PreferencesEvent.BREAK_LENGTH}" debug="false">
<PropertySetter generator="{ApplicationManager}" targetKey="breakLength" source="{event.value}" /></pre>
</EventHandlers> 

and use proper property getter/setter functions in my Manger like this:

private var _breakLength : int = 0;

[Bindable(event="breakLengthChanged")]
public function get breakLength () : int
{
	return _breakLength;
}

public function set breakLength (value : int) : void
{
	_breakLength = value;
	dispatchEvent(new Event('breakLengthChanged'));
}

I’m not sure what the general community at large thinks? I’ve started a thread over on the mate forums to discuss it, but it would be great to hear other peoples opinions on what should be best practice.

So, I set out to implement this feature and got to thinking about multi-screen support. Everything screen related takes place in the flash.display.Screen class. I thought there might be a simple method or property to return the current screen index a particular nativeWindow is on; but there isn’t really anything quite that useful there.

The closest thing you can get is Screen.screens which is an array containing individual Screen objects, one for each screen plugged into the viewing computer. From there, you have to implement your own routines to determine which screen a nativeWindow is on.

I wrote up a quick example that demonstrates how to determine which screen the window is on, and also how to store the window position and restore it next time the application is loaded. It’s called TwoScreens, and you can right-click to view the source (once you’ve unzipped the AIR file and installed it).

There may be a better way to do this, so post a comment if you know better ways to achieve this.

I’m glad I did, because it is an awesome framework with much flexibility making it suitable for many different types of projects. One of my favourite things about the framework is how quick and easy it is to integrate. It doesn’t force you to use all Mate concepts either, providing endless options for partial integration into existing projects that might just need a little structure.

One of the issues with Cairngorm that a lot of people have trouble with is easily responding to events/commands within a view (albeit the event that dispatched the event or not). I was happily surprised when I found out this is one of the easiest things to do within Mate, and there are two ways to do it!

Mate advocates the Dependency Injection pattern over the Model Locator pattern which Cairngorm advocates. Dependency Injection is a fantastic concept and truly promotes reusable views as the view needs no knowledge of the framework. Your view doesn’t really need to respond to an event directly, it just receives only the required or updated data it needs.

The second means for views to directly respond to events is using the Listener tag, which simply could not be any easier to work with.

I’ve worked up a basic yet focussed example on two options for repsonding to Mate events within views.

I plan on discussing other Mate features in future posts, but thought this was a great starting point as it’s the source of pain for many Cairngorm developers. Although, Universal Mind have released some extensions which make responding to events/commands within views much easier.

I decided to use MATE rather than Cairngorm in a personal project I’m working on, to check it out in a real world environment (there’s nothing like going beyond examples and prototypes to determine if a framework actually works beyond design patterns and theory).

So far, I’m very impressed.

It’s light weight, easy to integrate, and has a tag to suit almost any situation and many common design patterns. Within half an hour, I had MATE integrated into my project, dispatching events and updating the model.

I did however come across an interesting problem which had me stumped for a while. I’m working on an AIR application in which I have a preferences window (via a NativeWindow popup) which creates, stores and modifies preferences for the application (yes, I’m using as3preferenceslib).

The basic idea behind MATE is to dispatch events and respond to those with changes to the Model using dependency injection to keep your views notified of the changes. All of this happens via a tag called EventMap (MATE is a tag-based framework) which is used to respond to events, change the model and inject changes to data into views. Basically, you whack the EventMap tag into your Application.mxml, use the standard dispatchEvent and magically, everything works.

Unless you’re view is used in a popup window and you want to use MATE events and the model.

The reason being popup windows within AIR have an entirely different displayList to the Application displayList and your EventMap won’t be able to intercept events dispatched using the standard disptachEvent.

After some poking around in the MATE documentation (which is very good by the way) I found a Dispatch tag, which can also be instantiated via ActionScript. So, I simply made an instance of Dispatch and used the dispatchEvent method and once again, magically, everything worked.

var countdownEvent : CountdownEvent = new CountdownEvent(CountdownEvent.SET);
countdownEvent.countdown = event.newValue;

var d : Dispatcher = new Dispatcher();
d.dispatchEvent(countdownEvent);

Like the US our mobile numbers need to be 10 digits long, but Australian mobile numbers must start with 04.

I’ve used this in a number of projects and decided to break it out as an example of extending the Validator class to write your own validation routines. You can download the source (including the Unit test) from the example page.

The basic premise of Cairngorm and the ModelLocator pattern is that each Command (responsible for retrieving data from the server via the ServiceLocator pattern) retrieves the data and then updates the Model with the new data. In turn, your Views can then respond to changes in the Model via Flex’s baked-in data binding. This is one of the most useful features of Cairngorm and makes it perfect for large scale Flex applications.

But what about the times when you don’t want the Command to change the Model? One of the downsides of the ModelLocator pattern is if you go sticking everything in the model, it will quickly become polluted.

There has been much discussion in the past about how to best deal with this situation:

• Alex Uhlmann’s post How Business Logic Can Manage Views
• Derrick Grigg’s post Cairngorm, Commands, Views and Harikiri
• Thomas Burleson’s Cairngorm View Notifications

This time around we chose Thomas Burleson’s View Notifications resolution. It seemed to make perfect sense, it was clean and easy to achieve.

After successfully implementing it (which really was simple), I can definitely recommend View Notifications as a means to respond to Commands directly within your Views!

It seems Thomas and the Universal Mind team are looking to formalise this and some of their other Cairngorm extensions.

Datagrids are also very handy for showing only a limited number of object properties until the user selects a record, generally resulting in a detailed view showing more or all object properties.

You need to be careful however, ensuring you avoid common pitfalls such as loading large data sets all at once, using up more memory than you need to causing the application to feel sluggish and slow.

A fantastic approach to avoiding these situations is to use the Lazy Loading design pattern via a Ghost.

Lazy Loading is the practice of deferring initialisation of an object until the last minute (or the point it is actually required). Using the Ghost implementation of Lazy Loading allows you to load an object in a partial state; or put simply, load only a subset of the objects properties until all of them are required.

The properties you would load initially are those you want to display in the datagrid, and the rest could be loaded and injected into the appropriate object once selected in the datagrid and the detail view appears.

We have a datagrid showing a list of clients (an ArrayCollection containing ClientVOs, which lives in model.clients).

We need to provide the functionality to edit a ClientVO, and save the data back to the database. When constructing the edit view we had to decide to either pass the ClientVO to the view by reference or to pass the ClientVO to the view by value.

The events we had to manage when exiting from the ClientVO edit view where:

• Save. Save the ClientVO to the database, but do not exit the edit view.
• Done. Save the ClientVO to the database and exit the edit view.
• Cancel. Exit the edit view and discard any changes.

The Cancel event basically forced us to pass the ClientVO to the view by value, which gives you great flexibility on editing a local (to the edit view) version of the ClientVO.

However, it does mean you need to force the edited ClientVO back into model.clients (so that the datagrid contains the new values) at the correct index, effectively replacing the old version of the ClientVO and not an unrelated ClientVO.

I’m not sure if there is a Design Pattern that supports this, or demonstrates how to handle this better.

A common and easy method to randomly pick an item from a list, is to use an Array. Fill the Array with the available options and then randomly choose one, like so:

var a : Array = ['first item','second item','third item','fourth item'];
var s : String = Math.floor(Math.random()*a.length); 

What happens when you want to increase the chance of the ‘first item’ being selected? A simple option is to add more occurrences of ‘first item’ into the Array, as follows:

var a : Array = ['first item','first item','first item','second item','third item','fourth item'];
var s : String = Math.floor(Math.random()*a.length); 

I’m not a mathematician, but in my experiments this method increases the chance of ‘first item’ being selected; yet still being completely random.

I’m not really sure how others do this, but I usually grab an example application (such as the Advanced Cairngorm Store) and start ripping out all the bits and pieces I don’t need. This is a laborious and boring task, so I decided to do something about it.

I created a set of Cairngorm Stub Files (setup under the com.example path). They contain stub-code/files for most of the Cairngorm infrastructure that you would usually use in a Cairngorm project.

The files make a nice starting point, and because there are so many bits and pieces to the Cairngorm Framework, they also act as a nice cheat sheet to all of the classes, and patterns in Cairngorm.

Let me know if you find any bugs and I’ll update the stub files.