Both Web and native applications have their pros and cons. Let’s start with some of the examples of the native applications that exist today.
Bank of America’s native mobile application allows you to deposit checks by taking a photo of the front and back sides of the check and entering the amount. At the time of this writing, they support iPhones, Android, Windows phones, and iPads.
Near Field Communication (NFC) technology allows NFC-enabled devices communicate with each other in close distance using radio frequencies. NFC can be used for payments (no need to enter passwords) and data sharing (contacts, photos, et al.). Proliferation of NFC in banking will seriously hurt the credit cards industry. A number of smartphones already support NFC technology (see http://www.nfcworld.com/nfc-phones-list). Add one of the existing fingerprint biometrics solutions, and your mobile phone becomes your wallet.
While native applications have full access to all hardware of the device (e.g. camera, microphone, et al.), they have drawbacks too. For instance, if you want to publish your application at Apple’s App Store you have to submit your application in advance and wait for an approval. If a crucial bug is found in your application, even though if you could fix it in a day, you can’t put a new version in production until it went through an approval process. Back in 2011 Financial Times (FT) decided to stop using their native iOS application because Apple wouldn’t share the data about FT subscribers. Don’t forget that Apple would get their own cut from each FT subscription.
On one hand it’s good to have an ability to publish your latest Web applications on your own servers without the need to ask for a permission. On the other hand, the presence on Apple’s iTunes is a good channel for bringing new customers. The publisher of New York magazine is heavily investing into their native application for iPad but the newer versions of their Web applications are as engaging as their native piers. If you Web application has to be discoverable and visible by search engines, Web application are definitely better.
The hybrid applications promise you to have the best of both worlds. A Web application written in HTML/JavaScript has access to the hardware of the mobile device via a third-party library such as PhoneGap.The PhoneGap recompiles HTML/JavaScript code to create a platform specific application with an embedded Web browser, where your HTML/JavaScript code will run. This embedded browser (a.k.a. Web View) is chrome-less and your application is getting access to full size of the device screen.
The PhoneGap packaging tool takes your HTML/JavaScript/CSS code, compiles it for the required mobile platform and create a native application that has access to the native functionality of hardware, for example, if you need to deploy it under iOS, you’ll get an IPA file, and for deployment on Android devices you’d be getting an APK file. The hybrid applications may be not as fast as the native ones, and the architects responsible for defining mobile enterprise strategy must setting their priorities.
If a particular application will be used only by the employees of the organization who will use limited and defined number of mobile devices, and if making employees productive is the main goal - develop native applications. Start with developing and deploying such an application for the pilot OS (typically iOS 6 or Android 4), and then gradually add support for more platforms, budget permitting. If you are planning to develop a Web application with relatively simple UI (e.g. Save Sick Child) and have to support a wide variety of unknown consumer devices (e.g. allow people make donation from any device) - develop a HTML5 Web application.
Consider developing a hybrid application for anything in between, and in this chapter we’ll create a hybrid version of our Save Sick Child application with PhoneGap framework. To be more specific, we’ll access the camera of the smartphone and will use the PhoneGap PayPal plugin to process donations.
|
Tip
|
For current list of available PhoneGap plugins for various mobile platforms visit the github repository at https://github.com/phonegap/phonegap-plugins. |
First of all, PhoneGap is not a competitor of such mobile frameworks as jQuery Mobile, Sencha Touch and the like. PhoneGap is a technology for creating an application container that can run inside the HTML5 code written with or without using these frameworks. So when you submit a mobile application to the App Store of your choice, it’s packaged the same way as a native application for the selected platform. Besides offering such packaging, PhoneGap provides the JavaScript API for getting access to the hardware of mobile devices.
|
Tip
|
Display messages using Phonegap’s navigator.notification.alert() and the user will see native dialog box in his mobile device. The Notification object also supports confirm(), beep(), and vibrate() methods.
|
|
Note
|
PhoneGap is a brand own by Adobe. On the other hand, Apache Foundation has an open source project called Cordova, which started from the code donated by Adobe to Apache. Lots of developers from around the world work on Cordova, but Adobe’s using this library to create their own way of compiling and distributing mobile applications, which is branded as PhoneGap. The closest analogy is the Chrome and Safari browsers built on the same open source rendering engine Webkit. |
Even though this book is about HTML5, the authors would rather work with compiled languages that produce applications to run in virtual machines. Such software platforms are more productive for development and more predictable for deployment. While writing this book we were often arguing about pros and cons of switching to HTML5, and so far we are concerned that the HTML/JavaScript/CSS platform is not ready for developing of the enterprise applications just yet. We live in the era when amateurs feel comfortable creating Web sites and that JavaScript provides flexibility and customization the Access and Excel provided in the old good PC times.
Till this day Microsoft Excel is the most popular application among business users in the enterprises. They start the application locally, it has a local storage that enables work in the occasionally-connected scenarios. Both the data and the code are physically located close to the user’s heart. Microsoft Excel allows the users to have her own little pieces of data and amateurish-but-working-code (a.k.a. formulas) very close and personal. Right on the desktop. No need to ask these IT prima donnas for favors. No dependencies on the connectivity or some mysterious servers being slow or down. The most advanced business users even learn how to operate MS Access database to further lessen the dependency from IT.
But there is only so much you can do with primitive tools. Visual Basic was "JavaScript" of the nineties - it had similar problems, but nevertheless had huge followings. Now the same people are doing JavaScript. If we don’t break this cycle by adopting a common to all browsers VM, we are doomed for going through the generation after generation of underpowered crap. We wrote this book to help people with understanding of what HTML5 applications are about. But make no mistakes - the world of HTML5 is not a peachy place in the future preached by educated and compassionate scientists, but rather a nasty past that is catching up bringing the mob with it.