PhoneGap Architectural Considerations

PhoneGap is an application framework that enables developers to build natively installed mobile applications using web development technologies.  These apps are natively installed on iOS, Android, Windows Phone, Blackberry, Tizen, Firefox OS, and others, all leveraging HTML for the user interface, CSS for layout and styling, and JavaScript for interactivity, dynamism, and interaction with native-OS functionality.

When building a mobile app with PhoneGap you have a lot of flexibility.  It supports:

• Common frameworks
• Multi-page apps or single page/AJAX apps
• User interface libraries
• The option to build everything by hand
• And more 
  

Unfortunately, there is no single pattern that covers every developer in every use case.  Different developers have different skill sets, and different apps have different requirements.  Some apps target a single platform, while other apps target multiple platforms.  There are lots of permutations …

In this article, we’ll try to highlight everything that you need to consider when building a PhoneGap application, from the app architecture and code organization, to user interface paradigms.

General Architecture

There are two basic approaches when building PhoneGap applications: single-page apps, where a single HTML file is loaded and every aspect of the user interface and interactivity are generated dynamically at runtime with JavaScript (AJAX apps), and multi-page apps, where the app is broken into multiple discrete HTML pages.

Single Page Apps

I generally recommend that developers go with the single-page app architecture over a multi-page application architecture.  The general approach is that all of the application logic exists in JavaScript.  There is a main index.html file that contains links to all of the JavaScript files required for the application.  Once the page loads, the JavaScript is used to initialize the application and render the HTML for the user interface.  In normal circumstances, the web view never unloads the main index.html file.  Any time there is user input, data is retrieved from storage, or from other user interface changes and the HTML DOM is updated within the index.html file in-memory via JavaScript.

This approach enables you to create web apps that feel more like apps instead of web pages. Once the PhoneGap js library has been initialized, you never have to re-initialize it. By leveraging the single-page architecture, you will not lose data that is resident in memory, and you can manage the transition of content from one visual state to another.  Many MVC/development frameworks leverage this approach for building applications.  However, if you are leveraging the web view’s history management, then you have to manually manage URL fragments and history behaviors.

Multi-Page Apps

Multi-page applications function more like traditional web pages.  Each “page” or HTML file contains a finite and discrete set of functionality, and has limited client-side dynamic updates.  A page is loaded, content is displayed, the user interacts with it, and then another page is loaded.  These pages can be loaded from the local file system or from remote servers. This style of architecture works for many developers, however there are three notable drawbacks to this approach. 

First, there is the transition between pages. Not only are there visual display artifacts when pages are loaded and unloaded, but you also lose anything in-memory in JavaScript.  This includes framework libraries, collected data, and so on.

Second, you must include the PhoneGap JavaScript library in every page that you want to be able to interact with the PhoneGap APIs.  The native side of the PhoneGap API will only be loaded once when the application loads, but every HTML page that is loaded must include cordova.js, and each one will have a “deviceready” event that is triggered once the PhoneGap JavaScript APIs have been initialized for that page.  Even if you load cordova.js in your first page, any subsequent page will not be able to access the PhoneGap APIs if it doesn’t include cordova.js. 

Third, with this approach, there is not much differentiation between the app and a mobile web site.  If your app is too much like a mobile web site, it may get rejected during the app store approval processes.  Apple’s App Store is notorious for this, and it is explicitly stated in the Apple’s iOS Human Interface Guidelines that apps exhibiting “Web Based Designs” will be rejected.

JavaScript Libraries, Frameworks and MVC

As I mentioned earlier, there is no single solution for every application.  Different developers have different opinions and skill levels, and different apps have different requirements, so you must consider the use of JavaScript libraries, frameworks and MVC paradigms on a case-by-case basis.

JavaScript Libraries

There are lots of JavaScript libraries out “in the wild,” and it seems that the number of JavaScript libraries increases with each day.  Whether it is jQuery, Ext.js, underscore.js, or some other library, each is intended to make your development experience easier.  These libraries may be for manipulation of the HTML DOM, managing interaction with the server, encapsulating specific tasks like data visualization, or something else entirely. 

While many of these libraries are incredibly helpful, you don’t always need them.  It really depends on what you are doing, and you need to consider a few things before leveraging existing libraries. Here are some pros and cons to consider:

Pros:

• JavaScript libraries can provide familiar and easy APIs for common tasks, greatly increasing productivity.
• JavaScript libraries can encapsulate logic so the developer doesn’t necessarily have to be an expert to execute a common task.

Cons:

• JavaScript libraries often include cross-platform logic/detection, which adds file size and additional computational logic to perform a given action.
• JavaScript libraries can have bugs that might be difficult to track down.
• You must pay attention to all open source licensing for JS libraries – you can be breaking the law by using them if you aren’t in accordance with the license.

Frameworks and MVC

I won’t blindly state that “framework XYZ is the best” because this just is not the case.  Again, it depends on what you are trying to do. In general, frameworks provide structure for building your applications along with solutions for common tasks and consistent coding patterns.  These features are extremely helpful, especially if you are involved in team-based development. 

MVC (Model-View-Controller) frameworks enforce common coding practices that separate the data (model), from the presentation logic (view), and from the application control/services logic (controller).  MVC paradigms are especially helpful on large-scale applications not only because they enforce discrete coding patterns, but because they also enforce granularity of code structure. This leads to codebases that are generally more organized, have more code reuse across modules, and are easier to maintain over a longer period of time.  MVC codebases often are more complex, and require a higher degree of programming knowledge when compared to simple inline scripting. However, in my opinion, their benefits outweigh this cost. 

If you are developing applications that target multiple platforms, MVC architectures also can help you develop a codebase that is optimized for each device/platform classification.  For example, you can leverage the exact same data model and application/service control code. However, each platform can have customized user interfaces tailored to that platform’s experience.

There are generally two types of framework structures used in PhoneGap/JS applications.  In the words of my fellow Adobe evangelist Christophe Coenraets, we’ll call these full-stack frameworks and partial-stack frameworks.

Full-stack frameworks attempt to cover every aspect of your application, from code structure to user interface.  Partial-stack frameworks are those that cover individual components of the overall architecture.  In this case, you may have one framework for UI components and styling, another for MVC structure, another for DOM manipulation, and another for module/dependency management. With the partial-stack approach, you pick and choose which libraries you wish to include.

Let’s consider a few full-stack frameworks: Sencha Touch, Kendo UI, jQuery Mobile, and Enyo.js are all full-stack frameworks that offer touch-friendly, user interface controls with their own application architectural patterns.  These frameworks offer complete solutions for developing applications from user interface to general architecture, with specific code patterns. 

Now, let’s consider a few partial-stack frameworks (these are often used in conjunction to create an overall architecture): Backbone.js, Angular.js, Ember.js, and Knockout.js are MVC-style frameworks that provide separation of concerns.  They enforce coding practices and enable the separation of user-interface views from data model and application flow/behavioral logic.  These types of frameworks generally lead to fine-grain reusable components and well-organized code. However, they are simply architectural patterns, and do not offer user interface styling or essential utility functions.  They need to work with jQuery, Underscore.js, or another JavaScript library for general productivity methods.

Topcoat and Twitter Bootstrap are user interface frameworks that can be very helpful when developing PhoneGap applications, and are often used in conjunction with the architectural frameworks mentioned above.  These frameworks provide mobile user interface styling and reusable controls for developing your mobile applications.  Simple considerations of a polished user interface go a very long way toward a quality user experience.

Require.js and amd.js are JavaScript file and module loaders.  These are dependency management systems that ensure scripts are loaded when you need them, and help you manage JavaScript memory scope.  This is especially useful for large-scale applications and team-based development.  These do not enforce application-architectural patterns, but work with other common JS libraries and frameworks, including jQuery, Backbone.js and many others.

Optimized Services Architecture

Building successful PhoneGap applications is not only about client-side architecture; you also need to consider services that are in high fidelity with the user interface that is being used to consume their data.  This isn’t something specific to PhoneGap applications, but all mobile apps in general.  It is important to respect the operating environment of mobile applications: They are on devices with limited computing power, and are often used on broadband networks with limited bandwidth.  Structuring your services to return only the data that your app needs when it actually needs it will streamline the performance of your application.

Let’s consider a hypothetical scenario: You have a mobile app on a phone.  In this app, you have a list of 1,000 objects, but you only need to display the name and ID for each one of these records on the initial screen.  Once you select an item in the list, you will need to display additional data with more than 20 additional properties for the selected object.  When you initially request the list of objects from a server, you could retrieve all 1,000 objects with their full attributes and nested objects, or you could pull down only the name and ID for each object.  By optimizing the service to only pull down required data when it is needed, you reduce the file size of the data object that is being returned.  This speeds up serialization and deserialization, and also speeds up actual transfer time over the network because the response packet is smaller.  When you need to go to the second screen, request the full data for that object alone.  If you were to request all attributes of all objects in the initial request, the initial request would take longer to transfer, longer to serialize, and longer to deserialize/parse.  This is actually a very common scenario, and simple changes in architecture can dramatically help improve the user experience.

In Conclusion

You have lots of options when building your PhoneGap applications.  All the tools of the web are at your disposal to create the best apps possible.  You can choose libraries that you already know and love, or start from scratch with your own custom code.  When choosing what you want to use, just don’t forget about what you are building, who you are building it for, and how those decisions might impact the end user’s experience.  The faster and more responsive you can make a quality app, the more your users will love you.

This article was commissioned by Intel and the Tizen Mobile Web Development team.