Going Mobile: Wrapping an existing web application in Cordova/Phonegap

Going Mobile: Wrapping an existing web application in Cordova/Phonegap

There are many choices to build mobile applications, from native to the growing popularity of hybrid development, with everything in between. In all of these cases, as a developer you would be writing a brand new mobile application from scratch with the ultimate goal of deploying to one the app stores. Let’s say that a company has an existing web application and for reasons we will not debate here, management has decided that this web application is to be packaged and delivered as a mobile app available from the main app stores. How would you go about it from a development perspective and what would be some of the pitfalls and difficulties to take into account when engaged in this endeavor? This article will attempt to cover these and offer some solutions based on actual experience.

Design

The first and most crucial problem that you will have to resolve before doing anything is ensuring that:

  • Your web app is responsive
  • Your web app uses mobile friendly form controls

The second point is actually quite important if you’re using custom controls that will not be rendered natively by the mobile browser (I am looking at you Bootstrap dropdowns). You will have to scour your application on a mobile screen to ensure that the experience is consistent and frustration free for your target users. I emphasized target here because if your goal is to keep your application available through the web but still be available as a mobile application, I can almost guarantee that you will run into design issues where one platform will have to be favored over the other for optimal design so be prepared to make these choices when they come up.

Assuming that your design is now mobile ready. How do you go about wrapping into something that will feel native to your users?

Phonegap/Cordova and the InAppBrowser

Adobe PhoneGap is a distribution of Apache Cordova and Cordova is an open-source mobile development framework that allows you to use standard web technologies — HTML5, CSS3, and JavaScript for cross-platform mobile development. In simple words use standard web development tools to create and deploy mobile applications from a single codebase across different platforms. Phonegap offers some additional enterprise services for the development and deployment of your Cordova application but in essence you will always be working with Cordova under the hood.

What’s interesting about Cordova is that it can be extended using plugins which allow your app to use native device capabilities beyond what is available to pure web apps. That is how your standard HTML, CSS and Javascript codebase can hook into the phone’s camera or microphone to perform native functions, reinforcing the illusion of native to your app’s user. One of these plugins that can be made use of to wrap an existing application into a native app is the InAppBrowser who started as an independently developed plugin before being incorporated as a core Cordova plugin. It’s basically a child web browser that allows you to access third party web content. Wrapping an existing web application as a native application comes down at this point to loading said web application in an InAppBrowser window and managing the whole mobile app experience.

In practice, the loading is the easy part, with the managing of the mobile experience come the hard parts.

Cross Window Communication

Outside of just authentication, there will be many instances where you will find yourself wanting to communicate values between the wrapper app and the wrapped app in the inAppBrowser window. This great article by TJ VanToll lays the foundation for how to to just that even though it dates from 2013. Basically by making use of the inAppBrowser executeScript function, and using localStorage, you can exchange values between both windows. It’s not a standard way of operating but while waiting for Cordova to implement the window.postMessage specification in the InAppBrowser, this remains the most effective way of going about cross window communication.

Authentication and Session Management

If your application only consist off content that does not require authentication, you’re home free. Skip the rest of the article and enjoy yourself a cold drink. For the majority of cases the existing application is without a doubt functional only after authentication. With authentication also comes session management not only in the context of your application but also in the context of your user being on a mobile phone with the expected corresponding behavior. The following questions need to be answered

  • How long does the session last once the user is authenticated? In web applications, users are used to re-authenticating every time their session expire but on mobile, the expectation is to authenticate once and forget it, or use other less intrusive mechanisms like fingerprint reading or pin entering when security must be enforced. The takeaway is that you should not make the user have to enter a username and password every time they open the app if they really don’t have to.
  • Is your Forgot Password application flow mobile friendly? Does it require users to perform steps (Captcha) that are easy to do on a computer but would be more challenging on a mobile device? If not, you will have to adjust your flow to use more mobile friendly techniques (verification codes sent by SMS or Email).
  • What happens to your application when the user navigates away from it? Do not assume that your application will always be front and center, what happens when a call comes in and last longer than your session duration? What happens if the user sends the application to the background and then comes back to it a couple of days later? How would you know the state of the application at that time?

These questions show that even though the goal is to simply wrap an application in an hybrid app, to ensure an optimal mobile experience you will sometimes have to write additional code in the hybrid app to handle these different situations. For authentication and session management, the general idea is for also the hybrid wrapper to be aware of the authenticated and session state of your application.

Cookie Authentication

If your application uses cookies for authentication and session management and you don’t need to add an extra layer of security or convenience like fingerprint authentication, you will need to make sure that when opening the InAppBrowser window, you set the proper option for the window to remember cookies, otherwise if you kill the app and re-open it, your session cookies will be gone and the user will need to re-authenticate:

var ref = (url, target, options);

From the documentation:

options: Options for the InAppBrowser. Optional, defaulting to: location=yes. (String)

The options string must not contain any blank space, and each feature’s name/value pairs must be separated by a comma. Feature names are case insensitive. All platforms support the value below:

location: Set to yes or no to turn the InAppBrowser‘s location bar on or off.

clearcache: set to yes to have the browser’s cookie cache cleared before the new window is opened

clearsessioncache: set to yes to have the session cookie cache cleared before the new window is opened

The clearcache and clearsessioncache options are available on both Android and iOS and for clearsessioncache it should be set to no to ensure that your session cookies are remembered.

Token Authentication

If you’re using a token based authentication strategy and want to add fingerprint or pin-based authentication, you will need add extra code to the hybrid app to check for the state of the user when the app opens and present them with either a login screen or a fingerprint/pin reader. Refer to the Cross Window Communication section on how to communicate this state between the wrapper and wrapped apps.

External Links

A (nasty) little gotcha from using the inAppBrowser is that clicking on a link to external content, while you are in a inAppBrowser window will load that content in the inAppBrowser window you are using which leads to the following scenario:

  • User is enjoying your app thinking it’s native as your design job is excellent.
  • User sees a link to let’s say a Twitter page and “clicks” on it
  • The Twitter page loads in the InAppBrowser window, replacing your app with the Twitter page where your app screen used to be.
  • Extreme confusion ensues as the task manager shows that the user is indeed using your app, but they have no way to get back to your app content on iOS, or have to use the Back button on Android, and at this point the magic of native feel is broken.

The expected behavior would have been for the link click to open in a new OS Browser window, keeping the application intact and allowing the user to get back to it once they are done.

The solution in general is to track every external link with a script and open them using the window.open(url, '_system') call as illustrated here. Remember that this script will have to run in your wrapped app to work otherwise you will need to communicate the link url back to the wrapper app and issue the window.open call.

Android Only: Back Button

On Android you will have to be careful and plan out what happens when the user clicks on the Back button whether it’s a hardware or software button. If your wrapped app is a SPA, this can leads to some weird situations with your app state.

First thing to know is that there is a configuration for it in the InAppBrowser launch options:

hardwareback: set to yes to use the hardware back button to navigate backwards through the InAppBrowser‘s history. If there is no previous page, the InAppBrowser will close. The default value is yes, so you must set it to no if you want the back button to simply close the InAppBrowser.

If it is set to yesand your SPA handles back history fine, if the user gets back to the first page in your history and touches the Back button again, they will be taken back to the entry page of your wrapper app! Again not optimal and it breaks the experience of native and leaves the user confused again. One way to handle it would be to listen to the exit event on the InAppBrowser window so that when it is closed, the wrapper itself also is closed. Check this StackOverflow issue for alternatives.

Angular Only: ngZone for event handlers

After working with Cordova/Phonegap for a while and installing plugins, you’ll become familiar with how Cordova exposes functionality through events and event callbacks or promises. One gotcha if you’re working with Angular (>v4) is that these are events that are happening outside of Angular and if you remember even from AngularJS, any event happening outside of AngularJS needs to be synced with the AngularJS digest cycle using the $scope.apply() function. It’s no different in Angular expect now that Angular run in zones and uses the ngZone.run() function to re-enter the Angular zone. If you have Cordova plugin events firing and you are not able to tap into them in Angular, make sure to capture the event within a run function call as illustrated here in this example service for the Back button event being fired.

import { Injectable, NgZone } from '@angular/core';
@Injectable()
export class BackButtonService {
constructor(private logger: DebugLogService,
private ngZone: NgZone) {
document.addEventListener('backbutton', () => {
this.ngZone.run(() => {
console.log('Back button has been pressed')
});
}, false);
}
}

Summary

Although the initial goal of wrapping an existing web app into a native mobile app might look simple enough with Cordova/Phonegap, in practice there a quite a few pitfalls in making sure that the experience is optimal for users and fulfills their expectations for what a native app experience is. Behind the scene there will be quite a few orchestrations to put in place to maintain the illusion of native. I would then only recommend this approach as a stop gap measure while either a more appropriate native or hybrid app is being developed. Even they don’t work on Safari yet thus making them a more limited choice at this point, Progressive Web Applications are also a very viable option when targeting mobile applications.

Advertisements

Developing a mobile app with Phonegap, AngularJS and ExpressJS Part I

As a side project, I have embarked lately on the task of developing a mobile application with what ended up using Phonegap, AngularJS and ExpressJS. The gist of the application is to allow users to sign up and be able to share financial tips. I will document my journey along for others who are thinking of travelling down the same road, starting with my choice of technologies, this being my first attempt at building up the whole architecture from the ground up and since I am a front end developer and I wanted to leverage that experience to build a mobile app instead of going native.

Why PhoneGap and AngularJS and not Sencha Touch or Titanium?

When deciding on the initial approach to building the app, I initially thought about using Sencha Touch. I had tried Titanium before but had found it unwieldy although I like the whole integrated IDE to production setup. I work with ExtJS on a daily basis so I figured Sencha Touch would be a natural complement but after working with AngularJS, I really did want to keep getting better at it and not have to duplicate my learning by both doing Angular and Sencha Touch at the same time so i settled on PhoneGap after reading this tutorial (must read, you need to also read this here ). My time outside of work is very limited so I have little patience for frameworks with a high learning curve. I love working with AngularJS and adding Yeoman to the mix just makes it a breeze to work with so I was set on my front end tools.

Why ExpressJS?

When deciding of what framework to use for my API I initially tried Laravel, a PHP Web framework I had heard good things about it and it did not dissappoint. With the right instructions, the set up was a breeze and I had a basic API setup quickly. I liked the overall organization of the framework but at this point, I spend 90% of my time writing Javascript, so again, I wanted to stay within a single frame of mind for this project. I had always looked forward to finally trying out NodeJS , so server side Javascript it was. Given its nature, NodeJS can be unsettling because you are basically writing your own webserver, and coming from a background where you had to deals with the Apaches and Tomcats, it takes a little while to accept that new paradigm. Freedom can be overwhelming and I needed some structure to this whole new tool so I dug up ExpressJS, which is a web application framework for Node. I also decided to use MongoDB for my database, so I needed to find out how to make ExpressJS and MongoDB work nicely together, and Moongoose provided a good abstraction for interaction with my MongoDB database. Overall understanding the ExpressJS architecture, the concept of routes and middleware was the most challenging part of this part of the journey. I ran into Locomotive and I am not so far along that I can’t refactor using it as it adds convention over configuration.

API, API, API…

This is my first time building out a RESTful API as opposed to just using and it brought up considerations that I briefly wondered about before, the first one being how do I protect my API since this will be a closed system, I just want my mobile app to talk to my API. As a front end developer, those are considerations I never thought that deep on. I had to consider each strategy (Basic and Digest Authentication, API Key, OAuth, OAuth2), and how it would affect my implementation in AngularJS as well. This is the part that to a degree I am still pondering about but I am not letting me stop from moving forward.

Yeoman

Starting up was easy following Brian’s Ford instructions, I actually use Eclipse as an IDE where both my PhoneGap project and ExpressJS applications reside. There is a NodeJS plugin that exists for Eclipse that I use to run my API server initially but then I found Nodemon, which monitors my app for changes and restarts the server automatically. All of my Angular code resides in the assets folder of my PhoneGap project where I instantiated my Angular project using the yo angular generator. If you have not used Yeoman before to manage your web development projects, I strongly recommend it.

I create all my controllers, directives and services through the yo command as it also creates the proper accompanying unit tests. One small tip here, you might be wondering where yo gets the name of your app from when creating the angular module for your application and how to modify it so that you don’t have to keep changing the app name every time you create a new file? Change the “name” property in your bower.json file and yo will use a concatenation of that name and the “App” suffix to name your Angular modules.

AngularJS & Mobile Development Libraries

I am using Angular 1.1.5  as it adds a angular-mobile resource which adds better support for click events on mobile devices.  I initially thought of using Jquery Mobile even though I had a lot of apprehension about its speed but my app won’t be doing anything fancy UI wise, just presenting and collecting information. There is a plugin called the JQuery Mobile Angular Adapter which allows the two libraries to work nicely together but I could not get it going from the routing point of view, I was trying to do my application routing through AngularJS and it just was not playing nice, maybe due to my ignorance so I gave up on it and decided to stay entirely in AngularJS . I decided though to make use of the Angular Mobile Nav plug-in for my main screen and it worked as expected right out of the box with little configuration. There is though a promising project integrating JQuery Mobile and Angular called Angular JQM which instead of using adapters for JQuery mobile provides native Angular directives for JQuery Mobile, removing the need for the 3rd party libraries. As far as development itself it’s your typical Angular app so nothing new there.

NB: Doing bower install angular will get you the latest stable branch, to get the unstable branch you need to point Bower configuration for Angular dependencies to Pattern Consulting bower repo. This is what my bower.json looks like:

{
 "name": "appMobile",
 "version": "0.0.0",
 "dependencies": {
 "angular": "PatternConsulting/bower-angular#1.1.x",
 "json3": "~3.2.4",
 "jquery": "~1.9.1",
 "bootstrap-sass": "~2.3.1",
 "es5-shim": "~2.0.8",
 "angular-resource": "PatternConsulting/bower-angular#1.1.x",
 "angular-cookies": "PatternConsulting/bower-angular#1.1.x",
 "angular-sanitize": "PatternConsulting/bower-angular#1.1.x",
 "angular-mobile": "PatternConsulting/bower-angular#1.1.x",
 "angular-bootstrap": "~0.4.0",
 "angular-ui": "~0.4.0"
 },
 "devDependencies": {
 "angular-mocks": "PatternConsulting/bower-angular#1.1.x",
 "angular-scenario": "PatternConsulting/bower-angular#1.1.x"
 }
}

Another gotcha is that when trying to deploy your PhoneGap app to your phone or emulator for testing in Eclipse, you might run into an AAPT error such as:

"[2013-07-16 01:20:35 - appmobile] /projects/appmobile/assets/app/bower_components/angular-cookies/docs/partials/api/ng.directive:a.html: error: Invalid filename.  Unable to add."

This is because of the dot in the file name. Simple solution is to delete the “docs” folder in all your angular-* folders under bower_components.

Design

I have absolutely zero design skill so of course I am using Twitter Bootstrap, and the plan is to have a designer spruce it up once development is complete. One thing I have noticed is that I find the height of text inputs to be too small. Holly Schinsky in her excellent introductory article mentioned Topcoat which I had never heard of before, and it looks good so who knows, I might give it a run on a feature branch.

Summary

The process has been interesting to say the least, and it leads sometimes to second guess myself but that is the process of learning. I will keep up updated as of my progress, issues and findings in subsequent posts.

Leverage your web developer skills for mobile development

In the world of mobile application development, you can either build applications the standard way, which means using Objective-C to write Apple iOs applications, or Java with the Android SDK for your Android applications etc etc, you get the point. But a new paradigm has appeared that is very appealing to web developers like me as complementary to a skill set I already possess: writing mobile applications using HTML, CSS and Javascript. The tool that makes this magic possible is called PhoneGap and version 1.0 has just been released to I bet, the delight of many mobile developers out there. The concept behind PhoneGap is simple:

  • Build your app using HTML and Javascript
  • Access the native phone APIs through the PhoneGap wrappers
  • Deploy to multiple platforms

The appeal here is reminiscent of the early Java slogan, “Write Once Run Anywhere” or WORA, for those who still remember, and PhoneGap is even lauching a beta for PhoneGap Build, a service that will allow you to “write your app using HTML, CSS or JavaScript, upload it to the PhoneGap Build service and get back app-store ready apps for Apple iOS, Google Android, Palm, Symbian, BlackBerry and more”.  There are a  number of Javascript frameworks out there that can be used to build apps in conjunction with PhoneGap, the  two most popular are JQuery Mobile and Sencha Touch. Both are very capable frameworks that make use of the latest advances in CSS3 and HTML5. Your choice in a guttural way would depend on your familiarity with their browser counterpart (JQuery or ExtJS). What you have to understand at the end of the day with the PhoneGap architecture is that your finished app would basically be a web page running within a browser. Here are a couple tutorials to get you going either on Sencha Touch or JQuery Mobile.

Combined as I mentioned earlier with the fact that by using HTML, CSS and Javascript the learning curve for a web developer is suddenly cut into mere hours instead of the days or even weeks required to learn and master a new heavy language like Objective C or Java, you have to wonder how come every mobile developer out there is not rushing to adopt PhoneGap. Well there are limitations when it comes to building an application using PhoneGap and here is a shortlist (By no means exhaustive, feel free to inform me of more in the comments, I will add them to the list) :

  • Running from within a browser your app won’t have the native built-in styles available unless you use CSS to mimic them. There are frameworks that have been created to that effect. Sencha Touch comes with two default themes for iOs and Android and there are JQuery Mobile Themes available as well.
  • Performance will take a hit because of the extra layer between the app and the OS.
  • Access to the some of the native phone high level functionality is sometimes limited.
  • Support is sometimes hard to come by for specific issues, since this is a community supported project.

Those issues withstanding, I still think that PhoneGap is only poised to get better, and improve support for more native functionality. I think it is complimentary to my web development skills and allow me to expand into a new market without really stepping out of my comfort zone. If you are worried about native feature support or exploiting more of the native SDK, you should definitely look into Titanium, from Appcelerator which offers to “translates your hard won web skills into native applications that perform and look just like they were written in Objective-C [iPhone and iPad] or Java [Android]”.

Here is a list of links I found useful on the matter:

Android Development: PhoneGap’s “No such file or directory” Error

I was following the tutorial on the Phonegap wiki to set up the example project within the Eclipse SDK and ran into this issue where PhoneGap could not find the phonegap.jar under the framework directory:

`stat’: no such file or directory android-sdk-path.bat
D:/Development/Android/example_android/framework/phonegap.jar (Errno::ENOENT)

I had followed the previous steps and was puzzled by this error. It turns out the issue was the version of Ruby I was using was the issue. I was using 1.9.2 and scaling back to 1.9.1 got rid of the error and i am now able to build fine. I was getting also previous errors about the android-sdk-path.bat missing and those were due to the PhoneGap bin directory missing from my PATH variable so make sure to update your path correctly and you will be good to go!