Skip navigation

Tag Archives: patterns

Some really interesting things are happening at andCulture these days. In addition to rocking the CSS/HTML/jQuery/AJAX suite of technologies, we’re building libraries for Flex like never before–using Flex for both back-end application-y RIA software and also as the framework for very rich UIs that look nothing like an app.

We’ve been consuming data from .NET, both SOAP and AMF, and from PHP via AMFPHP. Jason Kichline (@jkichline) has been doing some really interesting things with building abstraction classes in a project codenamed SudzC (SOAP classes for Obj-C / iPhone).

For most (ok, basically all) of our Flex projects we use PureMVC, which is elegant, language agnostic, and quite minimal. However, it’s not without its drawbacks. Being language agnostic is nice when you want to develop for multiple platforms and not have to switch out your paradigm-parser, but not so hot when you actually want to take advantage of a platform’s stuff–like for instance, Flex’s event model. PureMVC rolls their own Observer pattern, which is really nerdy and wot not, but sometimes, you just want to use event bubbling / capture. And not have to implement Pipes.

Another interesting challenge of extracting a framework is finding the balance of modularity in encapsulation, and ease of use, so your team can actually build stuff quickly with it. For instance, we’ve got some solid application logic in our MVC, but you might want to switch out where the data actually comes from and not have to trust the developer to ensure that the Notifications are all where they need to be.

Screengrab showing basic package structure of AdeptivMVC

Screengrab showing basic package structure of AdeptivMVC

Our answer was kind of a crazy synthesis of a solution for each of these problems. First, we wrote a Plugin / Provider methodology for our framework, not unlike the Provider metaphor in .NET. So, our Model (Proxies) tell the data where to *go*, and *how* it interacts with the application, but Providers interact with the Proxies to actually *get* the data. Pretty nifty. Oh, and while we were at it, we kinda just rewrote PureMVC.

We’ll see if it works out. Basically, you know those times where if you have to trip over that creaky stair *one more time* you’re going to go totally ape and remodel the entire downstairs? That’s exactly what happened.

My mission was to take out all the annoying things about PureMVC and keep all the cool things. Kinda like Palm did with Pre and the iPhone.

Testing it basically involved taking an existing PMVC application and seeing A. how difficult it was to retrofit the new framework and, B. make sure it still works. So far, retrofitting the “AdeptivMVC”, as I’m calling it, is totally easy to do, and regression testing seems to prove that stuff still works.

Now, we also get the added niceties of being able to use Singleton proxies if you want, and have multiple observers in a many-to-many relationship within the app. I added a “Relay” pattern in the mix verus the Multion thing that is used in PMVC, which basically makes things a hierarchy which allows for some neat event bubbling tricks.

I’ll try to get some demos and things up, maybe work on the Adeptiv framework initiative on adeptiv.com, and maybe even have some time to sleep in between doing billable work! Afterburners, engage.

If you aren’t using an MVC framework like Cairngorm, Model-Glue, Guasax, or PureMVC for your Flex development, you really should think about starting. Our adoption of PureMVC at andCulture has allowed us to structure our ideas around a concrete paradigm and move on to arguing about more important things.

I’ve implemented PureMVC in both Flash and Flex projects and I’ve noticed that #3 of this post really applies. I mean really applies. As a general philosophy, I believe it’s better to start out with as few Mediators as possible, and structure them (or it) around the logical parts of the application or module—not the View Components or even their hierarchy as much. And, when the Mediator starts to become cumbersome, think about refactoring. 

For instance, for a Flash kiosk I just finished, I more-or-less had a Mediator for each VC—not entirely, but I definitely ended up with a disorganized mess of Mediators, which I affectionately refer to now as Mediator Soup. 

One of the biggest issues is state. Often elements that have their own Mediators should actually be a complex VC with a single, intelligent Mediator. Or, if that doesn’t flow architecturally, approach the VC as a separate Module or component, with it’s own MVC, and interface to it via it’s own API.

I’ve noticed that this approach allows me to think of the application in a more logical way, and seems to keep the code cleaner. I’d appreciate any thoughts or feedback on this.

Follow

Get every new post delivered to your Inbox.