Rico on Flex

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!

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.

Continue reading ‘PureMVC Notifications’