I’ve been looking at Phonegap since it started, long before Adobe bought it in a desperate attempt to destroy it.
Up until now, I never got the chance to make something with it, but always had the doubt how good or bad the applications you could create were.
Last week I had an opportunity to take a look under the hood, and made the source code available on GitHub.
The big question was, can you make native apps using Phonegap?
What you mean by native?
According to this guy in order to make native IOS applications you need to program in Objective-C.
I say that’s misleading.
Native applications are applications that run on the phone and provide a
native experience, for which I understand at least the following treats:
- Can access all of the device API, address book, camera, etc.
- Access to local storage
- Zero latency feedback
- Interoperability with other phone applications
- UX should respect the device culture and guidelines , If you have those, why should you care about the language the app is written in?
The wrong reason to use Phonegap
At first sight you may think that the main reason to use Phonegap is program once, run everywhere.
In order to provide a native experience you will need to design the UX of your app for every platform you’re targeting, so at least the UX/UI code will be different.
Obviously you can use the same UI for all the platforms, but unless the purpose of your app is to alienate your users I wouldn’t try it.
Software should behave as the user expects it to behave, you would not create new affordances for the sake of creativity, don’t do it for the sake of saving money, because it ain’t cheaper in the long run.
So, no matter what you’re thinking about doing, save some time to read the UX/UI guidelines for each mobile platform you’re targeting.
The great Mike Lee would tell you that you even need a different team for each of those platforms.
WTF is Phonegap?
Of course not.
Phonegap is an extensible framework for creating web applications, with the following properties:
- The framework exposes an API to access the device different components
- The API is the same for the different supported platforms
- IOS 4.2+
- Android 2.1+
- Blackberry OS6+
So you’ll end up creating your app inside XCode, dealing with code signing nightmares and taking a lot of walks inside the Apple walled gardens.
And you will need to learn the Phonegap API.
It doesn’t have to be 100% HTML
The first reaction is to think that since Phonegap uses a webview you will have to create your application using only HTML, but it’s not the case.
The most common example is the TabBar and NavigationBar in IOS, plugins for those already exist, and lets you design a more native experience than the one you would get using only HTML.
Back button in there, it’s just a custom button with the back text. If you want to create an arrow like back button you’ll need to go
down the same path as if you were doing Objective-C IOS development.
There are many mobile frameworks available out there to be compared.
Almost everybody agrees in one important point:
JQM is sluggish and transitions doesn’t feel native enough, something I easily verified testing the app in my IPad I, even the
slider was sluggish.
Using Phonegap Plugins
Plugins are usually composed of two parts:
Usually you’ll need to copy the
h plugin files to the
Plugins directory of your project, you will also need to declare the plugins
being used in the
config.xml project file.
1 2 3 4 5 6
Using the native plugins from your applications is straightforward, you initialize, create, setup and show the buttons you want.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
As you see in the last image, the TabBar is shown in the native version and the HTML version side-by-side. The HTML version was created using jQuery Mobile.
Debugging is hell
Well maybe it’s not hell, but it’s not a pleasant experience either.
If you include the following line in your html using your own id:
You’ll have easy access to debug your app using weinre without the need to set it up, at least it’s good for HTML inspection.
console.log, even the guys at Phonegap are recommending the poor’s man debugger.
Update Raymond Camden pointed out in the comments that a better approach to debugging exists, specially with Safari and IOS6
Tools are picked for the team, so that’s what you should think about when choosing or not to pursue the Phonegap path. If you already have members on your team who are great at web development, Phonegap may be an option, certainly it’s fast for prototyping and seems to be a great asset for product discovery and validation.
Reviewing the main points considered to categorize a mobile application as native, web frameworks will provide you a sub-par experience regarding feedback, latency and usability. Using the Phonegap plugins to avoid it will only go so far before the cost being so high you’ll better be programming in Java or Objective-C anyway.
If you still have doubts, fork the code and give yourself a try.
And don’t forget to follow me on twitter