Rico on Flex

I’ve been trying to play around with the PureMVC framework during the past few weeks and I would like to post my thoughts on the subject. This will serve as my reference later on and may also be of help to others who are interested to learn the framework. One obvious thing I should point out is that the learning curve for PureMVC is quite steep. Familiarity with the concept of design patterns is a requisite to be able to understand the framwork.

Notifications are similar to Flex Events. This may seem like a duplication of function at first but as you gain more understanding of this concept, you’ll learn to appreciate its purpose. Also a major reason why notifications exist is the language and framework agnostic nature of PureMVC. This approach made it possible for PureMVC to be ported to other languages or frameworks, not just Flex or AS3.

I’ll now proceed with the discussion of the major components of PureMVC and how they behave in relation to Notifications. I recommend going through the Minimalist MVC Example first to gain an understanding of the components that I will be discussing.

Facade. The Facade sends only one Notification, the initialization event called startup by convention. It doesn’t listen to any other Notification. The Facade is also responsible for assigning or registering a Command with a Notification.

Command. The Command only takes care of one Notification, the one assigned to it by the Facade. The Command is automatically invoked, or more specifically its execute method is invoked, whenever the Notification assigned to it is sent or triggered. In the execute method, you gain a handle to a Proxy via the Facade to retrieve, store, or manipulate data. The Command may also send a Notification to trigger an update in the user interface via the Mediator.

Proxy. The Proxy cannot listen to Notifications. It however may also send a Notification that will trigger an update in the user interface. The Proxy takes care of retreiving and storing data and announcing these changes to interested UIs via Notifications. The Mediator listens to these Notifications and is the one responsible for updating the UI.

Mediator. The Mediator is the only one allowed to listen to Notifications. It may also send a Notification that will trigger a Command and in turn cause an update to the application’s data via the Proxy. After the data has been updated, the Proxy may then send an update Notification that the Mediator can try to listen to and react to by updating the UI. The Mediator is also responsible for listening to native Flex events dispatched by the UI. Usually the Mediator reacts to these events by sending related Notifications, this is often referred to as “translating” from a native Flex Event to a PureMVC Notification.

So far this is how I understood PureMVC’s Notification system. Feel free to point out any mistakes or inconsistencies in the post. I will be using PureMVC in all upcoming projects and will be sharing my experience and learnings through this blog.