It has been a great experience so far working with PureMVC. There was quite a huge barrier for entry due to its steeper learning curve but after gaining enough practical knowledge of the framework, my team was able to quickly implement most of the UI related logic and some business logic requirements of our project while maintaining integrity of the code. Now the only thing left to do is to connect the application to the data in the backend.
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!
