Presentation Model design pattern: multiple screen solution – part 1

Today I’d like to talk about Presentation Model design pattern because it’ll be so useful for anyone that is working on multiple screen project with Flash or Flex.
In latest months we lived in phrenetic mobile world where we have tons of new and powerful devices on the market with different screen sizes, different hardware and so on, on the other hand we have clients that are looking for new business opportunities and they are seeking a way to spend less but earn more.
So, one way to solve those problems could be find a way to deploy with the same technology in different devices (tablets, smartphones, computers…) saving time with great results!
That’s not a dream, it could be made with knowledge, architecture and a good developer or a team!

Our goal

For a developer find a way to have a good project architecture to maintain it’s so important, usually when you start a project you try to define the parts that could be re-usable in different part of the same project or in different project too.
So our aim is find a way to write less code but it will cover the project needs and that could be portable in different screens / operating systems easily.

What is Presentation Model design pattern?

My mentor Martin Fowler describes it with those words: “Represent the state and behavior of the presentation independently of the GUI controls used in the interface”  (here the full article of Martin Fowler).
In fact with this pattern we divide UI (components, movieclips, sprites…) from their behaviors; each view will have one and only that one presentation model and only the presentation model will interact with the whole architecture (like with model or proxy…).
Probably with this image you can easily understand better this concept (from Martin Fowler website):

Like you can see we have 3 class, AlbumTitle that is a view with a textfield, AlbumPresentationModel that is the presentation model of AlbumTitle and it has the copy of the view but storing datas inside and finally the main model Album where we have the data that could be used for the whole application.
There aren’t any connection trough the views and the application model because only the presentation model has access to the whole project, so the view is only a bunch of components and custom graphics, this it means that if you have to change UI on a mobile project for a different device, changing the views and anything else, you will have done your job.
In fact with this easy technique you perfectly solve our problem and you should create the same content for different devices changing only the views.
Probably your application in different devices will have the same functionalities but with a different UI dedicated for the OS is running on.
With this sample design pattern you’ll have a solid infrastructure that will solve the big problem to port the same application in different screen sizes.
So in next paragraph we can take a look on how to organize our files project.

Manage a project for different screen sizes

Another important thing before starts the project is understand how to organize the project for different OS, in fact if you work with Adobe AIR on Android you’ll have only the XML descriptor with Android permissions described in this file, on Playbook you’ll have another XML file dedicated to this platform and so on.
So, my suggestion is to organize the project in different projects that work together.
In this image you can see how I organize it for our final scope, I’ve a common project (Runtime Shared Libraries in this case but you can use also an Actionscript or AIR project if you work with Flash for example) where I’ll put all classes that are common for different target, so in my case all the presentation models, main models, utils classes, my notification bus and views that are common for different projects like components for example.

In the target device projects I add only what I need for that device, in this case only a couple of views and assets but in big projects could be more stuff that those one:

When you have a specific behavior only for a target device, you can easily extends the common presentation model and add new functionalities or create a side class that you’ll add in the specific view.
So with this infrastructure you can solve bugs and change stuff directly on the common project and all the platforms will be ready to package the project and upload to their store. That’s cool, isn’t it?

Summary

So in this post I hope to give you some ideas on how to solve the big problem to create a common base code that could be useful for different purpose.
In next post I’ll show you how to implement it in practice, for now if you have any feedback or suggestions for the second part of this article please add a comment to this post.