In this post, I would like to discuss the general flow of an application built on top of PureMVC. This is how we understood the framework and it’s the approach we used for our application. The flow is actually pretty simple and straightforward, even obvious. We used the Multicore version of PureMVC but this discussion will focus on the Standard version.

The View

This part of your application contains the MXML components, Mediators, custom events, and maybe some Interfaces.

Ideally, you should create a separate Flex Library project for all your MXML components. In this way your UI guy can easily take ownership of that area of your project. He does not need to share any code from the other developers, he just needs to focus on one separate and independent area of the application. He practically just needs to checkout a separate folder made especially for him only.

These MXML components do not know nor care about PureMVC or any other architecture that you may have in your project. Their only concern is the user interface. They take care of input from the user by dispatching appropriate events. They also expose a minimal set of API that allows interested parties (the Mediator in PureMVC’s case) to manipulate the user interface.

One example of this API exposure is an “update” function exposed by a custom tab navigation component that requires extra UI-only processing such as transition effects, alpha, hiding, disabling etc. These extra UI related processing or logic is encapsulated inside the component’s exposed “update” function. You may also even go as far as define a standard Interface for all related MXML components to implement to make it even easier and more intuitive for interested parties to access their API.

The Mediator is the entity that connects the MXML view components to PureMVC. It has a direct reference to one or more of your MXML components. If you are expecting that one of your Mediators will be taking care of more than one MXML component, it’s good practice to standardize access to these components via a common Interface. However, this does not mean you only have to register the Mediator once, you still have to register the Mediator for each MXML component it is interested in.

The heart of PureMVC is its Notification system and a large chunk of that can be found inside Mediators. From the name itself, the Mediator “mediates” the flow of data and acts as a middle man between the View and the rest of the application. The way it does this “mediating” is through Notifications.

The Mediator listens to events dispatched by the MXML components and forwards this to the rest of the application using Notifications. Commands mapped to the Notifications will be triggered. The Commands may then perform business logic related processing such as comparing values and deciding based on those values. This will in turn update the appropriate Proxy or more succinctly, update the application’s data.

The Mediator also handles Notifications it is interested in especially those coming from the Proxy. Since the Proxy takes care of the application’s data, any change to it should also reflect on the UI. This UI update process is also accomplished through Notifications. We will discuss details of the Proxy and it’s role in the program’s flow in another post.

You can also directly access Proxies (Model) from the Mediator but I do not recommend this approach since this will tightly couple your Mediators to your Proxies. I suggest you limit the Mediator’s role to sending and handling Notifications and just leave Proxies to your Commands (Controller). We will discuss this relationship (Mediator <-> Command <-> Proxy) in detail in a later post.

Summary

Although I tried putting in everything I know so far about the framework, I’m sure I still missed a lot of essential stuff. Working with PureMVC entails continuous learning anyway so I’m sure we will be discovering more interesting things along the way.

I was planning to discuss all the aspects involved in the flow (the Model & the Controller) in this post but decided to split them into parts seeing that this post has become this long already.

So much good stuff to discuss, think in PureMVC!

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.