PhoneGap: An Unexpected Journey
Part 1. Theory
Chapter 0. What is PhoneGap?
And it is true(to certain extent). Lets take a deeper look:
Chapter 1. Origin
The web solved cross platform.
The ultimate purpose of PhoneGap is to cease to exist.
By and large PhoneGap creators are web consultants and they purely believe that web technologies are perfect fit for writing cross platform solutions. Actually, I totally agree with this one. Just think – on how many devices you can run a browser, in which you can run your app? I have one even on TV!
Also they believe that creating PhoneGap will help standardize web technologies. And according to their beliefs, when there’s no more need for PhoneGap(i.e. you can write native mobile apps with web techs without any frameworks) – their task is done. A brave goal, goal worth fighting for, imho, but a struggle won’t be easy. Well, good luck for them!
Chapter 2. Implementation
Windows.UI.Xaml.Controls.WebView class etc. General pattern is that this built-in browser behaves almost the same as native browser for this environment, e.g. Safari on iOS. Unfortunately, almost…but more on that later.
Chapter 2.5. Implementation. Learning the Magic.
As it turned out, js to native communication bridge implementation differs depending on platform, as you can see here(android) and here(ios). Furthermore, each platform has about 3-4 implementations, each fixing some bugs from another one. I can only imagine perplexity and frustration on brainstorming meetings while looking for new ways to handle new bugs in new hacks. Phew!I won’t cover all the ways of communication, but will give some tips.
Perhaps, you should!
Most of the work is done in NativeToJsMessageQueue.java class. The name actually speaks of itself. It’s a thread safe queue of js messages to be invoked on js side. This guy’s job is to deliver them. Internally he has 4 ways to do this, but I will tell you only about the default and the most hacky one.
Chapter 3. Architecture
Part 2. Let’s get to action!
Chapter 4. Installation
After few minutes of research I decided to run my first app on Android, as deployment process seemed to be very easy for a newbie, comparing to iOS(no need for licence, direct access to device, no VMs, as I use Windows etc).
So your main problem is setting up Android environment. Adding PhoneGap libraries is pretty easy. Just make sure you understand what’s going on.I was working with PhoneGap 2.2.0, maybe they fixed something for 2.4.0, but anyway this article was pretty useful for me. Although I recommend googling for newer versions.
Chapter 5. Development
The code seemed pretty much like:on Java, and
on html side. pretty simple isn’t it?
But it gets much more interesting when building something bigger then just a skeleton app. If you have ever dealt with Android emulator, you’d notice that it’s extremely slooooow. It takes from 5 to 30 minutes(!!!) just to check if your changes applied correctly! And also it happens often that some part of build process fails for just really random reason. Don’t believe? I wouldn’t. But it happens.
“Ok”, I thought, “then I can just develop and debug design and main functionality in browser and then simply move it into the app, there shouldn’t be much difference, right?”
This approach lead me to a very unpleasant situation, where my beautiful, good looking, bug-free static website turned into an ugly monster when displayed as an app. Actually, randomly-broken-functionality ugly monster. But more on that later.
So, advice no1 – go get the device! (although on iOS build process seems less painful).
Now, when you’ve got the device your development process blooms in every way. After you made changes in code, it takes about 2-3 seconds to see them applied on device(just use right shortcuts) . I’d say it’s feasible.
Of course, it wan’t solve all your migration problems, but at least you will get them one by one and in time :)
So, the development process goes like this: you edit the code in Eclipse, when ready – press smth like ctrl+f11 to build and deploy app to a device, look at device to see the app and decide if you need to change smth more. And what if you got a problem and want to diagnose it? Well, let’s talk about it.
Chapter 6. Debugging
debug in browser
weinre seems to be “official” PhoneGap debugger, according to url. It lets you navigate your html content as you dynamically update it. It has a similar interface to Chrome developer console, to give you impression that you’re home:) Although it’s a bit slower and less user-friendly then chrome debugger, it may save your day.
Let me put the magic out if weinre. Everything is pretty obvious – you put their script with your “unique” id into your html file(it’s not unique – you just pick non-common description of your app to find it between all the others later). This script sends ajax requests with information about page html and all that stuff periodically to their server to specific url based on id you chose. Then you go to their server using your browser, specify your id and server periodically returns new information about changes in your original html document. Then weinre js logic displays the results in a friendly way. Easy as hell.
It’s also funny to watch how many people currently use weinre with default id “anonymous” and expose all their data:) Yes, security IS the concern here, because all your logic is transported through third-party soft and publicly exposed to everyone who can guess you “unique” id.
And, as you may have guessed, your device has to be online in order to debug your app using weinre.
Chapter 7. Deployment
Deploying mobile apps is pretty different from deploying web apps. In web you usually had a web server with predefined ip address and/or DNS name, and users simply access you web site by typing your address in their browsers.
PhoneGap and AppStore
If you’re coming from the web, you need to make sure that you give people an iOS app experience, not a web experience.
So you still have to know their guidelines and iOS app UX. Same with Android, Windows and other platforms you’re targeting, although some of them may have weaker requirement for following them.
To ease your deployment process PhoneGap introduced thing called PhoneGap Build. Its a cloud service, that lets you forget about transforming your html,css and js files into Android or iOS app file.
In other words, you can write code on any platform, in any IDE(don’t bother with Eclipse, Visual Studio or Xcode), let PhoneGap Build handle build process for you, download apk, ipa or whatever file your platform uses, install it on your device(Android, iOS, iOS for adventurers) and see the result! Of course, it takes more then 2-3 seconds as opposed to Eclipse build. But still, when automated, this process can be pretty useful.
Also, I must note, that using PhoneGap Build is very intuitive and pleasant, good job done here.
Chapter 8. Experience
When it comes to reality, and you need to build some non-trivial app, deploy it to couple of devices, and then to maintain it later, you just think “never again”. The fact is that there is soo much mysteries around these built-in browsers that you can hardly manage them all. I personally still didn’t find an explanation to couple of bugs. And it can be a serious show-stopper for the business you’re in. So expect surprises, they will come.
Also, as I told before – you still have to know the guidelines of each platform and apply specific design for each of them, and it doesn’t just mean that you turn rounded corners into square ones, it also means that you redesign your view drastically. Moreover, there are sooo many devices out there, each supporting/not supporting specific feature… Do you really think you can use “One size fits all” here?
So now cross-platform apps has weakened in their meaning. Functionality is still very similar, but a bit different. And this “bit” messes everything up. And here come the phrases like “By the time your app redraws its view on click, you can go cook a nice fresh lasagna”, “PhoneGap is cross-platform. It doesn’t work on all platforms the same way.” or “Instead of dealing with N platforms you just have to deal with N+1”, and its almost true.
Chapter 9. Conclusions
So, we’ve processed a whole bunch of information. Let’s wrap it up.
The term “cross-platform mobile app” is a bit misunderstood. The application may work on any platform, but it won’t, or at least shouldn’t, be the same on all the platforms.
When using PhoneGap – you’re trying to save time and money, and may even succeed, but remember that you’re trading quality to gain this.
Building non-common solution with PhoneGap is a huge risk and will likely end up in a disaster.
Trying to build mobile app without knowledge of platform you target will end up in clumsy user experience.
PhoneGap is the best there is in its field. Don’t try re-implementing it on your own, as you will face same major issues.
When Phonegap may come in handy:
- You’re building near-trivial, common-purpose app with built-in controls and nothing extraordinary
- You’re having time shortage and need to deliver some results asap.
- You don’t have any Android or Java developer to build native app
- You need to support more than 2 platforms
- You need to support a platform so deprecated, that PhoneGap APIs are better then native.
Last word to say – respect to people who try to integrate web technologies into mobile devices. I understand and share you goals, but unfortunately, and it’s absolutely not your fault, the result is not satisfiable yet.