Our team is engaged in creating applications for mobile devices.

One application that we had worked on was written in four separate versions, for four different platforms: Android, iOS, Windows Phone and Windows. We chose this approach because the client wanted the application to look different when viewed on tablet and smartphone, but after we completed the work we were then asked to provide around-the-clock support for the application on all its platforms.

We calculated that to assure full support, we would need at least three developers – each with sufficient platform-specific knowledge – for each of the three platforms (in this case counting Windows and Windows Phone as one platform). As we only had a small team of three to five people, we were somewhat perplexed by the problem. We concluded that we should abandon the policy of maintaining all four native applications and instead adopt a hybrid approach. Hybrid solutions are generally divided into two types: those that allow the creation of an application with the use of web technologies (PhoneGap), and those that use a common API (Xamarin).

In general, hybrid solutions are those which cover at least two platforms. However, we only took into consideration the frameworks that would allow the creation of applications on all four platforms.

Web hybrids

Web hybrids require a rather different skill set from native applications. We had to exclude considering the use of responsive web pages based on window-size because we needed to use several platform-specific features and facilities. We also had to accommodate the fact that our client already had the application in shops on all the platforms and depended on the continuation of the product’s branding.

In this article, we’ll compare two alternative web frameworks: one based on jQueryMobile, and the other on Ionic. Having trialed both solutions by building mobile applications, I will describe the tools we used during development, the problems we encountered and our conclusions.

PhoneGap a.k.a. Cordova

PhoneGap was created by Nitobi in 2009 and since then has captured the hearts of web developers and sellers with its concept of writing the code once, and then launching on every platform. In 2011 Nitobi was bought by Adobe and the PhoneGap code was transferred to Apache foundation, taking the new open-source name – Apache Cordova. As such, in this article the names PhoneGap and Cordova will be treated as synonyms.

Figure 1: source: https://build.phonegap.com

PhoneGap is very simple in concept. Code written in web technologies such HTML5, CSS and JavaScript is, with the help of PhoneGap, “packed” into native projects and run in a web container – the application relies on the browser engine embedded on the mobile device in order to run (see Figure 1). Thanks to JavaScript being embedded inside the native application, it’s possible to use native components (such as GPS or accelerometer) by means of plug-ins fulfilling the role of a proxy between the device and the HTML application. Moreover, only one codebase is needed for all platforms, which is not the case with native technologies. The PhoneGap framework can be used to create projects on the following platforms: Android, iOS, BlackBerry, webOS, Windows Phone, Windows, Symbian OS, Tizen, Firefox OS, and Ubuntu Touch.

An application based on PhoneGap can also utilize server resources. This means that certain elements (e.g. CSS styles) are sent to the application from the server and are interpreted within the web engine. Thanks to this approach, the application can dynamically change appearance without the need for time-consuming upgrades through the store. The only question that remains is whether a mobile page would not be better in such cases.

Diagram 1: Tools delivered along with PhoneGap

Along with the PhoneGap framework, the programmer gets the opportunity to use powerful tools such as PhoneGap serv, PhoneGap Developer and “Cloud Compiler” (see Diagram 1). With PhoneGap serv, you can rapidly set up a local webserver, which simplifies exposure of the developed website to mobile devices. PhoneGap Developer is a client application for the aforementioned web server and is a mobile application available in stores for all platforms. After running the application, you are first asked to give a URL address of the PhoneGap serv local server. Next, the website from the local server is displayed in a web container. By using the application, testing time is shorter because it’s not necessary to go through the application installation process on the device each time code change has been made. Changes that are made on a local server are instantly propagated on all instances of PhoneGap Developer connected to the local server.

Lastly, Cloud compiler is a solution which aids Windows developers in compiling applications for iOS without Mac systems. In order for the application to be compiled, it is enough to send the code to the PhoneGap cloud. Cloud compiler supports three platforms: iOS, Android and Windows Phone 8.

The process of publishing a PhoneGap application on a particular platform is the same as with native applications; creation of the program, debugging, and testing are different however. Thanks to web technology, it is possible to check how the application works on a standard desktop web browser and this, in turn, allows the developer to detect logical or business errors early on. Plug-ins to native components are not supported in desktop browsers, so parts of the application have to be tested on the target physical device.

Environment

The following IDEs were taken into account for the application development process: Visual Studio 2013 with a Cordova plug-in and NetBeans 8 with a similar plug-in. Unfortunately in Netbeans, there are drawbacks: There are a limited number of built-in plugs; built-in configuration for plugins will overwrite plug-ins that are not built in Netbeans and are added via command line.

Visual Studio, on the other hand, (when this research was in progress) was limited Windows systems and did not work on MAC OS. Additionally, the current version adds superfluous files to the project which causes the code to fail synchronization between platforms: a different catalog structure to the default PhoneGap one is generated in a Visual Studio project. Visual Studio isn’t an ideal environment for the development of applications in Cordova. When you create the application in each environment, it is often necessary to use the console command for actions such as adding a new platform, installing a plug-in, compiling an application, or running the app on devices.

Debugging

A developer needs tools that allow problems to be diagnosed rapidly. When you are using web frameworks, you have powerful tools that are embedded in a browser that allow you to see what is happening in the application. A common problem is the browser safety policy that will intervene to block queries being directed to servers in various domains. This type of query is called a Cross-Origin Request, and the intervention can be overcome easily by running a local server (PhoneGap serv or NetBeans) and by setting a proxy in the configuration file in a server.

The greatest headache with debugging is when you use plug-ins that give access to native components such as GPS or notifications. Their activity can be tested only on a physical device; not in a desktop browser. The debugging process is then very difficult because helper tools often detach from the device. It would seem that that PhoneGap as an organization still has work to do to improve the debugging of web applications.

Application outline

In order to test out what we’d learned, and check how several mobile-ready web frameworks behave on real devices, we created a simple hybrid application with PhoneGap, using two alternative web frameworks.

The application was based on a “Master-Detail” scheme (a list of items plus a details view), as well as containing push notifications and a map. It presented data sets that were taken from REST services. Additionally, in accordance with our requirements, views were displayed differently on smartphones and tablets. An interesting question that arose at the very beginning of the exercise was “How much code will be shared among platforms? More, or less, than with Xamarin?“

Approaches

PhoneGap is only a “bridge” between the web page and the native application. Thanks to this, it does not restrict in any way the use, or choice, of web frameworks. When we created the application, we chose two base browser frameworks:

• Ionic (at the time in the beta phase) which is based on the well-known Angular
• jQueryMobile complemented in architectural aspects by Backbone and RequireJS

The application was created on the basis of an SPA (so-called Single Page Application) model. The system was therefore based on three key elements:

• Modularization – helping to define certain functionalities as separate components of application
• Routing – controlling the redirections between different application views
• Binding – supporting easy attachment of data to views

Moreover, outside of the mentioned components, it is possible to differentiate elements responsible for UI and maps (see Diagrams 2 and 3).

Ionic – Initial concept

Diagram 2: Ionic application architecture

First of all, a few words to explain why we chose Ionic. Many of you will certainly have heard about this hybrid platform over the last few months. Despite still being in beta, it has already found its way into the hearts of many developers. It is based on Angular, but introduces something revolutionary – the so-called native appearance of controls, meaning that controls take on the style that a native application would display. Moreover, in Ionic the basic components delivered by PhoneGap have been refined. A new “lab” component has also been created, allowing the developer to check the appearance of the application on any Android or iOS device. Unfortunately, from our point of view, Ionic also has some drawbacks: it is still, and has been for far too long, in the beta phase; our clients would prefer solutions that are fully released rather than “fledgling”. It also does not officially support the Windows platform and is incompatible with the coming Angular 2.0 version. In spite of these issues, we decided to test the strength of this approach and we think it was worth it.

Map view

In the first implementation, we decided to use Google maps; it contained most of the components we needed such as drawn shapes, pins, and popups. We observed that maps work slower on Windows than on the other two platforms. Additionally, tabs were visible on the page with the map. Just a few lines of HTML code were enough for the tabs to be adjusted to the device – on Android they were at the top, on iOS at the bottom; unfortunately, the Windows view was the same as iOS. Android and iOS made a great impression on us – we had not expected that the web framework could align layout at the speed of the native application. During implementation of the map view we utilized a Cordova plug-in for geolocation. Could writing mobile apps in web technology be really so easy?

List view

Figure 2: List view (Samsung Galaxy SII)

In the next task, the aim was to display map data in the form of a list. It was enough to add a few pictures and navigation (see Figure 2). The task would have been easy were it not for the fact that Windows is not officially supported. Out of the box, every element of the list can contain two icons; once more icons were needed, we were required to start our own list. And here the problems began…

The framework on Windows, for the first time, showed its horns as well as a yellow card. Icons on the list were not displayed and, in order to see them, it was first necessary to repair the routing – Windows had redundantly added URL prefixes. The solution was a work-around, but it was really close to a hack. By adding a new view, the list, which could contain multiple rows, became practically impossible to scroll on Windows and worked significantly slower on Android. Additionally, when something did not work on a single platform, it was fixed in the common code, which automatically led the chance of unwanted regression on remaining platforms.

Detail view

Figure 3: Detail view (Samsung Galaxy SII)

On detail view, only static information was displayed (see Figure 3). It was possible, for example, to “make a call” to a given number (using a native device capability), as well as to register for a push notification (this time using two new plug-ins: the first responsible for registration and receiving events, the second for checking the device’s platform – as each platform slightly differently handles a push notification plug-in). Unfortunately, push plug-ins were written procedurally (not using IIFE), causing unwanted global methods to appear in the JavaScript code.

The plug-in for notifications imposes a common reception of events for all platforms; it is an iOS approach. The moment that the application is switched off or is in the background, the user sees a notification on the task bar. On the other hand, when the application runs, information about push receipts are not displayed on the task bar. The developer must take care of the proper handling of received messages. It is worth remembering that this was the first time we had to retreat from full code-sharing, and when we introduced the first platform-specific checks.

Summary

During our assessment of the Ionic platform, we limited ourselves to smartphones. We decided not to proceed with developing the tablet interface because of problems found on Windows. The framework made a very positive impression on us as a result of its solid support for Android and iOS. The native appearance and faster-than-expected execution is something that, in our opinion, raw PhoneGap lacks. Ionic is the hybrid framework of the future as it was created especially for mobile platforms. While we await the final version, we’re keeping our fingers crossed for cooperation between Ionic and Angular – as well as for improvement of the support for Windows.

jQueryMobile – “The old dog”

Diagram 3: Application architecture – jQueryMobile

jQueryMobile has been available on the market since 2010. Over the years the framework has attracted a legion of fans. It has its advantages, as well as well-documented disadvantages which come with its age. Unlike with Ionic, we received a great number of controls which “out of the box”, look identical on all platforms. We were pleased to see that the framework supported all the platforms that were of interest to us. jQueryMobile was supplemented with additional web frameworks, allowing us to use SPA architecture, the most important being: Backbone, RequireJS and Underscore. These provide us with the appropriate structure for the project, providing modularity, binding and rendering of HTML and as such, create a substitute for Angular.

Map view

Figure 4: Leaflet map (Samsung Galaxy SIII)

This time our approach to the map was different. Because of our discovery of the way that google Maps slowed down on Windows devices, we checked competing maps. Bing Maps supported all necessary functions; however didn’t work well on iOS. Apple Maps, in turn, cannot be embedded in a WebView. As a result, the winner was a dark horse: Leaflet (see Figure 4). These maps deliver all the required functionality (shape drawing, pins and popups), worked well on all platforms, and have an extremely intuitive API. Similarly to Ionic, it was necessary to add a plug-in for geolocation.

List view

Figure 5: List view (Samsung Galaxy SIII)

This time, jQueryMobile stood up to the task and provided smooth scrolling of lists on all platforms (although the number of elements still influenced the scrolling speed – Figure 5). Fortunately, there was no problems with requiring many icons on the list. Only one question remained, namely the routing – utilizing an href tag attribute in a tab, on both Windows Phone and Windows, did not redirect to the next view. What is wrong with routing on Windows? Fixing the bug on Windows Phone does not in any way guarantee that the application will work on Windows. The problem was eventually solved by the replacement of the href tag with an onClick event.

In this approach, we were also able to implement a tablet version. In the case of Windows, this imposes a rigorous Microsoft policy regarding development using JavaScript. This occasionally means having to use platform-specific code, which has the consequence of compromising our aim of sharing code.

Detail view

Figure 6: Detail view (Samsung Galaxy SIII)

In this aspect the application behaved exactly as it did on Ionic.

Summary

Figure 7: List-map view (Galaxy Tab S 2)

The jQueryMobile framework, complemented by Backbone, RequireJS and Underscore, allowed a full implementation of the mobile application that looks different on a smartphone and a tablet (see Figure 7).

The greatest challenges during development were:

• The debugging process
• Running compiled application
• Investigating all the problems we encountered

jQueryMobile has already been on the market for a few years, so it has well-documented classes, methods, and hacks. Unfortunately, it works slower than Ionic and requires extra work to gain the native look of the application on all platforms. At least the platform met our fundamental expectation: it allowed us to share most of the code and generated fewer problems than Ionic.

Unit testing

We used Jasmine for Unit testing PhoneGap applications. It is a popular web Behaviour-Driven-Development (BDD) framework and thus its syntax is more descriptive, resembling a User Story, and this way, the tests focus on representing code behavior, which it supports. Tests can be easily executed on any browser.

Application size

The other factor that matters is the size of the application- for us it means the amount of space the system takes up on a physical device. The bigger the application, the slower the installation and upgrades. No user would want an application that merely displays simple lists to take up around 50MB.

In the case of the approaches we checked, the application used about 9MB of storage (for Android), compared with the native application – which had slightly more functionality – this was around 4MB. The size of PhoneGap wrapping is therefore insignificant. On remaining platforms, the app took up about 10MB and was about 5MB bigger than its native counterpart.

Summary

PhoneGap allows the developer to create hybrid applications using the concept of ‘write once, run on all platforms’ – however, platforms may differ from one another, and certain features that run out of the box on Android may require a lot of extra effort on other platforms such as Windows. This leads to the application code being less transferable between platforms. The ideal programmer for such an application would have 90% web developer skills and 10% native developer skills. The technology stack based on jQueryMobile was better. It is a framework with a long history, enhancement plans and decent documentation.

Our experience suggests that PhoneGap should be considered in cases where:

• the application is oriented on processing or displaying content rather than business logic
• development schedule is short
• the customer asks for both a web page and a mobile application
• the client has a responsive website and wants to add a mobile application
• we are bound by low maintenance costs (the tools and code need to be shared between platforms)

Regardless of the approach, there is no ideal IDE for developing hybrid applications in PhoneGap. During development we regularly used the command line. Debugging of the application is possible with the aid of a browser, but unfortunately is more difficult due to frequent disconnections of the debugging tools from the device. Tools for investigating potential problems are very important for any developer and, unfortunately, in this area there is currently no good solution.