Picking Your Javascript Mobile Framework: Part 1 - Preliminaries
Part 1 in a series that also includes:
- Part 2 – The Field
- Part 3 – Functionality
- Part 4 – The Code
- Part 5 – Performance
- Part 6 – Elimination
- Part 7 – Activity
- Part 8 – Documentation
- Part 9 – Ampersand
- Part 10 – AngularJS
- Part 11 – Backbone
- Part 12 – CanJS
- Part 13 – Durandal
- Part 14 – jQUery
- Part 15 – KnockoutJS
- Part 16 – Mithril
- Part 17 – Ractive
- Part 18 – React
- Part 19 – Stapes
- Part 20 – Thorax
- Part 21 – Vue
- Part 22 – Conclusions and My Pick
So I recently decided to switch from native mobile development to Javascript in a browser. What changed is that I needed something that works on more than just Android, and I faced the steep curve of dipping into iOS development. That’s a pretty steep one, because it doesn’t just involve getting into a completely new paradigm, but because you have to own dedicated hardware and pay an up-front fee to Apple.
But what do you know, Steve Jobs was right: the future of the web is in the browser. When the first iPhones came out, in 2008, the brilliant man said we didn’t need native toolkits. He said so mostly because he didn’t have one to offer, since back then mobile browsers were super-crappy and the web just wasn’t ready for them, anyway. Today, a startlingly short 6 years later, the mobile browsers are not only on par with their desktop cousins, they start becoming the default targets of development.
Instead of creating apps on the mobile device, you could simply send mobile users to your site. That would require no download, which means no headaches with old versions and no complaints from users that can’t make it work on their phone. On the other hand, you become unavailable when there is no internet connection, you are as slow as that very same connection, and you have no access to device internals – like the GPS or the accelerometer.
Quite a few frameworks have sprung up to bridge that gap. These frameworks allow you to create apps using mobile tools, give you access to the device’s internals, and deploy mostly locally. In essence, you create a mini-web site on the phone.
The most interesting of those is Apache’s Cordova project. It was originally developed by a company called PhoneGap, which subsequently got bought up by Adobe (of PDF fame). Smartly, Adobe decided to keep the infrastructure of PhoneGap free and open (hence the Apache connection) while it would make money on online offerings (very smart).
Cordova/PhoneGap is a hybrid: the apps it creates are native apps that wrap a web view (a browser window) that has access to the device APIs thanks to some glue code. So it goes APP > BROWSER -> NATIVE. To the user, that’s all pretty irrelevant: they get an app that works locally, pretty much the same on iPhone, Android, Windows Phone, and even BlackBerry.
“Pretty much the same” is crucial here. Some users complain that the web views offered by Cordova look just right but don’t behave just right. They are Frankenapps of sort!
To be fair, there are differences between a web view and a native app that are hard to bridge. It is also fair to say that a user doesn’t really care if an app is native or weird. What a user cares about is that an app shouldn’t do anything unexpected: if you have a native-looking app, it should behave like a native app. If you have a Frankenapp, make it look sufficiently different that nobody mistakes it for native.
In any case, Cordova does the trick. I looked for samples in the Play Store and tried them out. Worked really well. Then I tried a few apps to which the developers provided source code, and it’s tragic how few of them actually work. I confess I was close enough to despair many times, trying to figure out how to make them run, as if my ability to make a demo or sample or tutorial run was indicative of how easy it would be to make any phone app.
Then I decided to go for the home run. If Cordova was what it said it was, screw all the demos and samples that were Cordova-specific. Simply take a web site designed for mobile, shove it into a Cordova app, and see if it works.
I took the jQueryMobile demo as a starting point, because I wanted to see how that one behaves. To wit, I followed the following process:
- Create a dummy Cordova project:
cordova create ~/dev/cordova/jquerymobile com.mrgazz.cordova.jqm "Marco's JQM App"
- Unpack the jQueryMobile demo
- Copy the contents of the demos folder into the www folder of your cordova project:
cp -r ~/down/jquerymobile-1.4.5/demos/* ~/dev/cordova/jquerymobile/www
- Go to the jquerymobile app folder:
cd ~/dev/cordova/jquerymobile
- Run the app:
cordova run android
It will all start up if you configured everything correctly. You need to have a working Android environment and either an emulator setup or a device plugged in. But if everything is as it should be, you should see your app start up and display the demo main page.
Well, that wasn’t too hard! Now, it turns out that the links on that page don’t work, but that’s not Cordova’s fault. They are coded to go to the folder, which on a web server typically redirects to the index.html file. Here, it doesn’t (it’s not a safe assumption on a web server, either!). So you just go to the index.html page and fix the links. Wherever you see a link that ends in /, add index.html after it. The first one, for instance, reads:
<a href="intro/" data-ajax="false">introduction</a>
and you change it to:
<a href="intro/<span style="color: #ff0000;">index.html</span>" data-ajax="false">introduction</a>
Easy enough!
OK, so now we got to the fundamentals: ignore the demos, with a few exceptions, and focus on writing a good mobile web site. Putting it onto your phone is going to be a snap with Cordova/PhoneGap.
[Note: Cordova is definitely not the only player in the space, and there are a ton of options for mobile cross-platform development. The two most commonly used that I can tell are Appcelerator Titanium and Sencha Touch. You should definitely look at both those, maybe they are a better fit for you than they were for me.]