by Jonathan Campos
BlackBerry, iOS, Froyo, Gingerbread, Honeycomb, Mac OS X, Windows 7, Firefox, Safari, Chrome, Internet Explorer. There are so many places your application needs to run, and you only have so much time in your day to make sure it runs in all of those places. As the plethora of platforms, operating systems, and devices change around us, you need to work smarter not harder and architect your applications correctly to ensure they can be used everywhere.
In programming, the concept is DRY: don’t repeat yourself. By setting up your applications properly, you can reuse the optimum amount of code and save yourself the headaches of copying and pasting or over-complicated object-oriented programming (OOP).
The problem with multidevice development isn’t just getting over the multiple screen sizes. That is just one hurdle. Instead you are dealing with multiple devices that have different capabilities and a variety of hardware configurations. Luckily, Adobe AIR and Adobe Flash Player both run ActionScript and are formatted to run across platforms and devices.
In this article, I show you how to architect your application to run across multiple devices. In the process, I explore the idea of MVC, frameworks, and package organization to simplify your multidevice development. I use examples from my Netflix Queue Manager, an application that I currently have running on the desktop, Android, BlackBerry, and iOS.
Model-View-Controller (MVC) is an architectural pattern for software development. The idea is to isolate the logic that runs the application, the data behind the application, and the visual layer of the application. By following this separation of duties, you can break the application’s code into sections that can be easily separated from one another.
In this article, I do not address the ongoing debate of the specifics of MVC implementation within a framework. Instead I look at a specific framework’s implementation of MVC.
While I have laid out applications in all the main frameworks with great success, in this article, I reference Robotlegs because I enjoy the simple setup, built-in Dependency Injection (DI), and Inversion of Control (IoC). If you prefer PureMVC, Cairngorm, Swiz, Mate, Parsley, or your own homegrown framework, you can still make this work as long as you follow the concept of MVC.
The basis of your project will consist of a main project library and all the sub-applications that feed off of the library. Each application will be for a different endpoint: iOS, Android, desktop, BlackBerry, or web (see Figure 1).
Figure 1. The main project library and its sub-applications.
By using a library project as the core of your application stack, you can build the models, services, and utilities as well as all sorts of reusable classes into your library and include only the view layer and controllers in child projects. This way, each individual device application can handle the device’s input uniquely while the data models stay the same across all devices.
When you set up your application in this manner, make sure to communicate using events or signals and completely decouple your application. Using events is also a great way to handle application view changes among the different applications. By having a central event bus to dispatch events over any part of your application, you can listen for changes by models or user input.
Let’s look at an example. If you are using the “Hero” build of the Flex framework, you call to the ViewNavigator to push and pop views. Yet if you are on the web or desktop, you are likely using a ViewStack or some other way to move between application views. If you use events, then you don’t need to re-architect how your applications are changing views. Instead, a controller on the main application view of each device application can handle these view-changing events and move your application appropriately, thus simplifying at another level how your application operates.
Deciding exactly how to build your application is a bit more complicated. However, just because your application is special doesn’t mean that it can’t follow some simple rules:
The confusing part is just how much can you safely put into the library before your architecture starts to fall apart? The answer depends on how unique each device’s experience should be.
If each device will use the same look with just minor visual changes, then you can add your item renderers, CSS files, and visual assets to the library.
If each device will have a unique visual experience, then you may need to leave the CSS files, visual assets, and item renderers in each device’s application project. Common visual components can be added to the common library, along with a base CSS file to override Flex framework defaults.
I recommend leaving the views and the controllers (sometimes called mediators or presentation models) in the device-specific project folder because each device needs to use its own unique interaction model effectively.
See Figure 2 for an illustration of this concept with the Queue Manager application structure using Robotlegs.
Figure 2. Queue Manager application structure using Robotlegs.
Because you are splitting up your device applications and creating a single large multiscreen application, you will definitely need to perform some unit testing and build in some automation. I highly recommend that you create a build system to handle all these issues.
When you make a change to your model or service, you can quickly test your application across all device applications to see if your change has caused a conflict with any of your sub-applications. Conversely, if you make a change to an individual view or mediator, you can also test that change with the newest builds of your library.
Furthermore, you need a simple way to build all of your release files (.air, .swf, .bar, .ipk, .apk, and so forth) with one verified and trusted command. Building files with either ANT or Maven is a good solution. Both tools are extremely simple to set up, and you can find a few examples of each online.
While the concept seems simple, until you get into the groove of your application, you may find that putting specific files in the library vs. the device application will be your biggest headache. Multiscreen application development really isn’t difficult or even particularly time-consuming as long as you plan your architecture in advance and follow your structure.
For more information on multiscreen development, check out these posts by Christian Cantrell:
Jonathan is currently the Director of Software Development at Dedo Interactive in Dallas, Texas and co-owner of UnitedMindset. Jonathan leads various development teams and advises for multiple companies along with being an active trainer in Flex development.