PhoneGap Architectural Considerations
PhoneGap Architectural Considerations
Join the DZone community and get the full member experience.Join For Free
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.
Single Page Apps
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 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.
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.
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:
- 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.
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.
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.
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.
Opinions expressed by DZone contributors are their own.