Mobile Strategy Choices. Unraveled

This topic is obviously not new. Everyone talks about it. Sooner or later. After making these choices couple of times and talking with customers I noticed common misunderstanding, misuse and mistakes people do(and so did I). There are lots of great articles out there which help out deciding, but still I think it could be brought in a better form. And that's what I'm doing here. I'm delivering mobile technology choices in a form of Binary Decision Tree. I'm starting with the results, further on I'll cover it with the details, and in the end I'll give 4 case studies which demonstrate different choices.

And don't get me wrong. I don't like the idea of silver bullet work flow chart that makes the decision for you(though here's a good one, still I disagree with some points). This decision tree is intended to help you better understand the correlations between your requirements and corresponding technology. You can think of it as unraveling the cables behind that old audio/TV/any system. It's still complicated, but it's much clearer now.

So, how does it work? Basic idea is to define your requirements from the product vision, and then, by prioritizing them, go left or right in a tree. Then you repeat it until you've reached the leafs, i.e. the bottom of a tree. Pretty easy, isn't it?

Now let's delve into details.

Choosing between App and Web Site

I intentionally rooted my decision tree with a Vision, as this is a thing, without which you cannot start choosing the technology. You have to know what you're aiming for before you start shooting. Then, you need to turn the vision into some more specific requirements. I'll help determining the criteria, but there is still work to be done with setting the requirements and understanding them.

The first choice to be made is whether you want a Mobile App or Web App(Site). You probably heard of topics like "HTML5 vs Native." I think it's a bit confusing and too generic comparison, as with HTML5 you can build both web and mobile apps. My point is that you shouldn't choose between Native and Web. Native is a way of implementing Mobile App. Web is a whole family of apps, with its attributes and specialties. Instead, you should choose between Web and App approaches as they deliver more or less equal alternatives, cover different usage scenarios and reflect different marketing channels. And these are basic criteria you want to base upon when choosing mobile strategy.

So, the criteria. I'll start with the easy ones: if you know you're gonna need access to device features(gyroscope, accelerometer, bluetooth, contacts, calendar, push notifications), you care about security or you need non-trivial computation tasks - in these cases you can forget about Web App. You simply don't have required APIs for device features, you don't have infrastructure for security and web has been proven not to be able to deal with heavy-computational tasks.

Please note, I didn't include offline and camera access here on purpose. This is one of most common confusions people make in this field. Web has already grown to an extent where whole websites can go offline(and I'll give you an example later on). And about camera - there is a big progress and workarounds there so before eliminating web as a platform for your app it's better to make deeper investigation. I must say, in my humble opinion, HTML5 s moving(slowly though) towards accessing all these device features, so in future(far future) that will not be a show stopper.

Then, if you don't have a need for any of listed above, you need to define and prioritize the following criteria.

User Experience
Questions: What do you expect from user? How do you want to interact with him? Do you want him just to read information or to input something? How often do you want him to use your app?
Hints: Mobile apps are more adapted for interacting with users and entering information, although skilled web developer can nail it in the web. In contrast, when a user just googles for some information, he doesn't want to download the app, he just needs the piece of advice as quickly as possible. Yes, by the way, one fact you should always keep in mind - mobile users are much less patient than desktop users. As Eric Reiss, usability expert, states, the three-clicks rule is not applicable to the mobile environment. Users will leave your system the moment they feel it doesn't bring much use to them, i.e. possibly after the first click.

Content
Q: What is it that you're showing to your user? Is it a daily newspaper article, or a 3D model of his new house? Or maybe a medical record input form?
H: Content is tightly integrated with user experience, he actually defines it. I highlighted it as a separate criterion to help you better understand your UX strategy. Here's a good popular tip from Prasant Varghese:

If your goal is just to display and show content, I suggest a responsive or mobilized website. If your goal is to show productivity tools, build an app

Distribution Model
Q: How do you want to deploy your app? How do you want to deliver updates? How do you want users to reach your app? What is your maximal time-to-market?
H: Apple has started a very good culture with its AppStore. Apps there are easy to find, to choose between competitors thanks to rating & comments and have good compatibility model. Those are huge pros for mobile apps. The con would be bigger time-to-market because of Apple's and Microsoft's review process(if you're aiming Android, BB or enterprise that's not a  problem). Also, there may be scenario where you want to employ your own distribution model, or you already have good SEO rating for your website and just want it to go mobile. Choice is yours.

Monetization Model

Q: How do you return your investment? Is it a part of your marketing

campaign? Or are you going to monetize your application? Do you want to use built-in methods of payment?
H: Some build apps to sell them. Some to market their company. Some to improve their employees productivity. Anyway, if you want to deal with money, it's better to go the App way, as there are built-in user-friendly ways to handle money transfer from inside the app, or when buying the app itself. Again, if you have your own well-made monetization model you can go your way

Portability
Q: Who is your target audience? What devices are they using? Phones? Tablets? Phablets? Which OS? How much devices are your going to support? Is functionality the same for all devices?
H: Both App and Web can give you great portability, just for different cost. Going Web usually means (if made correctly) that everyone can use it. When going the App way, you'll have to pay more(Native) or less(Hybrid) for every new platform. Learn your audience and what devices they are using. If you have really diverse audience(e.g. you're a food retailer) and your customers have all range of phones from old Nokias to brand new Nexus' it makes sense to have a website which will cover them all. On the contrary, if you have more specific customers, like lawyers, who usually use iPhones, you can save some budget by cutting support of other screen sizes or platforms. One more advice - don't rely on statistics of browsing your (desktop) site from different operating systems too much . It is typical that user who has visited your site and didn't like it, won't visit it anymore. Better learn who do you want to use your system.

Budget
Q: How far can you go to reach the best quality? Where is "good enough" for you? What is the long-term planning?
H: For most people this is final word. Keep in mind cost of development, testing, maintenance, deployment etc. It's not a secret that App way will be more costly. You should also consider in what tools and technologies you want to investigate, i.e. what types of applications you are going to build in future.
Also, consider choosing both ways - Web and Apps for several platforms. Here's a quote from Jason King which describes budgeting very well (source)

Desktop, mobile web, and apps are all different marketing channels. You have to decide where to focus your development budget...If you have the budget, do it all.

A very popular scenario is to develop an app for most important audience and make a web site with limited functionality to cover all the rest. When budget is limited and functionality allows, the killer combination is HTML5 code base with tuning for accessing device features for Hybrid tools(PhoneGap, Titanium) and tuning for workarounds without these features for web site. But don't ask me about maintaining this code base and the number of branches there.

Also, note that I didn't give such popular criterion as availability of developers for right technology. I'm sorry, that's just too obvious for me. If you don't have people to use certain technology - then you can't afford it. Or, if you really need some technology - you'll find the people somewhere.

Just to use the right moment, here's another good source of topic that we were talking about.

So, we've made the most important part - we've set a line between an app and a site. Now we're going to see the difference in technologies for developing each. I like the polish notation, so will go to the apps first.

Choosing technology for the App

First of all, let me give my definitions of Native and Hybrid. I call Native the official way to build mobile applications, as declared by each platform's vendor, i.e. Java + Android SDK for Android, Objective C + iOS SDK for iOS etc. I call Hybrid all the tools to develop mobile apps in any other way. Still on Internet more accepted term for Hybrid is something between Web and Mobile App.

Now, to set the right angle for this conversation I'll start with the following fact. When each mobile platform was out, the only way to develop applications for it were the recommended vendors tools, i.e. native APIs and correspondent programming languages. Later, as the tools were a bit difficult to migrate from mainstream web development to uprising mobile development, people started inventing hacks, which could simplify this procedure. Remember ASP.NET? When Microsoft tried to help shifting desktop developers to web development with hacks like viewstate? Well, this is something similar. 

Another problem Hybrid tools solve is cross-platform development. So that you can build one application which would work everywhere. Without worrying how it works on all these platforms. But these hacking tools don't save people from learning all the aspects of mobile development. At least they shouldn't. And that's a very common mistake - to think that knowledge of language will save from learning the infrastructure. Sooner or later you'll have to deal  with the details. And same way we learned about hurdles with viewstate we'll have to learn about hurdles of Hybrid tools. And that's the way it is.

As for me, the choice between Native and Hybrid is the matter of investment. If you buy something expensive, you get good quality result, no head ache and smooth process. If you buy something cheap, and save money, it has to show up at some point. You get either worse quality, a lot of problems down the road or the high risk of failure. It's like buying tickets from resellers at the concert - they're twice cheaper, but you have no guarantee you'll get inside. So think twice, whether you want such an approach for your business.

Still there are situations where Hybrid can be the right choice without a big loss. I've set 5 criteria for choosing between Native and Hybrid approaches(which intersect at some points with your previous choices)

Future

The big drawback of Hybrid approach is that at some point you just might get stuck and not be able to implement something as when using Native approach. And although in most Hybrid tools there's a space for injecting native parts, it might get really tricky. So my recommendation is not to choose Hybrid if you see great extensions to functionality of your app in future.

Risks

Define the level of risk you can take. The risk of failure, the risk of higher costs of maintenance, of getting stuck and switching to Native, of immature technology and community, all the other risks. If you have a mission-critical project - go Native.

Portability

Again. If you target more then 2 platforms it makes sense to go Hybrid. But don't underestimate the cost of adapting the codebase to each platform. Write-once-run-everywhere is a myth. It's rather write-once-fix-everywhere. There are lots of design differences between Android, iOS and other platforms, which you'll have to take into account. Also building and deploying processes are specific to each platform.

Performance

Obviously, and as it was mentioned before, Hybrid apps are usually slower(although Cross-compiled seem to make a difference). The very well known fact is that Facebook dropped their Hybrid approach because it simply didn't meet the UX expectations from users and they didn't use it. When Facebook switched to Native it was a bliss for users and a shame for HTML5-believers. Though Sencha quickly responded to this. A lot of people use it as an argument for Hybrid apps. But I'll tell you one thing, this demo was built not as a Hybrid app, but as a Web Site. And it's a very well-known fact that hybrid apps are much trickier than websites, because WebViews are more limited then browsers(e.g. no Nitro engine on iOS). So if you got on this side of the tree because of performance or UX then it's very simple - go Native.

Budget

Of course. I've already said too much about it. No more comments.

Choosing between Hybrid technologies

It may be a surprise for someone, but people actually created a lot of ways just not to deal with Objective C:) No, just kidding. The idea of cross-platform development isn't new - we've had it with Java for Linux, Windows and the rest of the company, we had it with HTML5 for different browsers, there's similar problems in gaming world(PlayStation, XBox etc). It's absolutely normal to want your code to work across all the platforms. But the world is not fair, and this comes with the price.

So, there are basically three ways to write Hybrid apps. Two of them are very similar, which is why I've distinguished only 2 in a decision tree. I'm not going into too much details here, but I'll give basic idea about how they work, what are the differences and what are the choosing criteria.

WebView-based, aka PhoneGap

The idea is that you put a single control called WebView on native part(instead of building page control tree as it's done in Native way), and write all your functionality inside it. The WebView is kind of a web browser inside native app. This way, you build mobile application as static web site, but it will be a bit slower. The communication layer between native and WebView environments lets you use all functionality from native part by using special javascript APIs. In return you get a lot of head ache and mystery. For more details see my previous blog post about PhoneGap.

Custom container-based, aka Titanium

The idea is that you have a container on native part, inside which you execute your custom code (in Titanium it's javascript), and you have a communication layer between native and containerized part, so you can also access all native features. This container could be V8, Rhino, a mentioned WebView or many others. All container has to do is execute custom code and provide communication between 2 worlds. With this approach you generally do not build a mobile app as a static web site, you only reuse javascript code base. In further discussion I won't distinguish these 2 approaches as technically they are subset of one another and practically the pros and cons are almost the same, although their philosophies differ. Here's a good article from Appcelerator's employee comparing PhoneGap and Titanium.

Cross-compiled, aka Xamarin

The idea is that you write code in one language that will be later cross-compiled to other platforms' native code. This way you get both cross-platform code and native experience. Although you can reuse only core logic, you'll have to write UI for each platform separately. A fair limitation, imho. A bit confusing, and with a lot of questions(memory management, language specific structures etc), but a very promising approach. I personally like it because unlike containerized approaches it doesn't abstract you away from each platform's architecture. You still have to be aware of how each platform works. You just get your favorite language codebase across the project. A detailed article on Xamarin is soon to be released on elekslabs.com. 

Before comparing these I'll remind you - you're on this part of the tree because you are have the low budget, you accept risks, you don't expect a great performance or you look for great portability. 

To be honest, Cross-compiled looks like something between the Containerized and Native ways. A bit less performant then Native, a bit less portable then Hybrid, a bit more expensive then Containerized. But I decided to leave it on this side of the tree as it still provides great risks of unknown and the most representing platform is still on its maturation journey. If this wouldn't be a binary tree maybe I'd put it in the middle. Now, I see 4 criteria for choosing Cross-compiled vs Containerized.

Native Experience

How close to Native do you want to get? Now that you're in this risky part of the tree, you still can get good performance if you go Cross-Compiled

Platform Maturity

With all respect to Xamarin, PhoneGap is a bit older, and has at least taken its fair place in technology comparison. Not every average developer is aware of Xamarin and how it works, but most of them have heard about PhoneGap(good or bad stuff)

Preferred Tools

Hybrid approach is based on reusing existing skills. So if you are ready for taking Hybrid approach you can choose language and tools you like more. Me, for example, I feel more productive when armed with C#/R#/VS then with JS/N++ although I love both.

Portability

Third time in a row. I'll say it quickly. As Xamarin apps can't reuse UI part, it's a bit harder to migrate code base across platforms with Cross-Compiled.

Few, that's it, we're done with all the apps stuff. Just to take a fresh breath I'll share the beauty which inspired me while writing this article.

Choosing between Web technologies

There are 2 popular ways of building mobile-friendly web site: making a separate web site for small-screened devices or making a web site which would fit to all kinds of screens, i.e. a responsive web site. Let's see how they can be compared and when to choose which one.

Screen Size Range

It's a similar question to portability. How diverse is your user base? Do you need to support every couple of inches or is a common 3-4 inch enough for you? Do you want to support Tablets?

With Responsive approach you'll have a good appearance on all kinds of devices. If you want to achieve it with separate site, you'll have to build couple of them, for different screen sizes each. But usually a separate site is done when only mobile phones are in focus and average appearance on tablets is satisfactory.

Support

If you have 2 web sites, you must understand how much more difficult it is to support them - from fixing bugs to changing content. In terms of support Responsive wins the battle

SEO

As with Responsive you've got only one site, you have the ranking summed up from mobile and desktop devices. That's a big advantage for discoverability.

Full Redesign 

All these benefits come with a prize. To build a Responsive site you usually need a full redesign of you existing site, which would of course cost more then just implementing mobile-friendly version. In case you're building a new site , it's not a problem. But if you're in a middle or running business and have just recently updated your web-site's design you have a tough decision to make.

Budget

There are lots of discussions on Internet about which approach is cheaper. The general agreement is that Responsive is cheaper in a long-term, but more expensive in the beginning, especially if you're dropping your previous design to make a brand-new mobile&tablet-friendly web site.

To keep you reading here are some interesting articles comparing these two approaches.

Ok, now we're done with decision tree, and to wrap it up I'll give you couple of case studies which prove all the text above.

Case Studies

All case studies here are examples of the projects we did here on ELEKS. The fact is that the most popular decision among our customers is opting for the App. But we also had less obvious technology choices, and I'll share them with you to demonstrate how diverse requirements can be and what technologies they fit the best.

An all-platforms App for Time Tracking

Back around 2005, when all enterprises were still on BlackBerry, we were in a middle of a huge project, developing product for lawyers' time-tracking. The system worked well without mobile part, but the time has come and mobilization took it's part. 

The purpose of product was to simplify reporting process for lawyers and help them create and manage records. And mobile phones was a great enhancement to general idea. Records could've been created based on calls received, emails read and meetings attended. And that's exactly what customer asked us to do. As we needed to support only BlackBerry, and the budget was fair, no one even thought about other ways then building apps the way RIM recommends to. And that even wouldn't be possible as we needed access to a lot of device features. Decision was made, application was built, everybody was happy.

And then iPhone came out in 2007. We couldn't reach same functionality because of platform limitations, but still it was a native app. At some point of communication with customer  there was an idea to switch to Hybrid, but the decision from customer was very clear - the product is meant to improve lawyers' productivity, so it needs to be on top of user experience practices. And couple of years later we started developing Android version. So we have an app running on 3 platforms, and it's still Native.

A Mobile Web App for Healthcare

At 2009, we had a lead from one US customer, asking us if we could build mobile medicare software product. The functionality would be not far from common - inputting information about patients, receiving some information from server etc. Although there were tricky parts, like supporting offlline mode and syncing with server when going online. Customer wanted the app for iOS, Android and possibly other platforms. We evaluated the functionality, and identified potential simplification with HTML5  which wasn't so much HTML5 back then. Still even then, there was a documentation on Offline Manifest and local storage with doubtful support among browsers. To make it clear, the idea of cache manifest is to include a file in your web site, which will tell the browser which files it needs to cache locally, so that if user visits web site again without access to internet, the browser opens the cached version. So we made a prototype and it worked! (not without surprises of course). At least on out target browsers, mobile ones, it did. Customer was more then happy for a double cost reduction and a little change in user experience(opening browser bookmark instead of opening the app) was more then ok price for such a big save. So we were glad to win the lead and the customer was glad to save money. As far as we know users are very satisfied with the system too. What a love story! For more details you can read this document.

A Hybrid App with Native injections for Logistics

Somewhere around 2008-2009 we had a task to implement a small app to help couriers do their job more effectively. Each one of them would receive an Android tablet, and every morning all of them would had a list of new orders, which was shared between them. Everyone could pick orders that was closer to him and everybody else would see it. This process was managed by coordinator and his responsibility was to deliver all orders. Also, when courier delivered the order he asked to recepient to sign on the tablet(yes, physically draw the signature over a tablet with a stylus), which would generate a PDF document, that was saved on server then. When choosing, our main priority, brought from customer, was budget. So we looked for ways to do it cheap. The functionality wasn't that difficult, most of development time was estimated for UI controls, as we needed a long grid with checkboxes, buttons and other custom controls. As Android was still raw back then, and we had good web specialists, we decided to try a Hybrid approach, by reusing Ext.js controls and therefore saving a lot of time. But take into account - there was no PhoneGap at that moment. And this solution was even more riskier then it is now. And we had to implement our own communication layer between JavaScript and Java. Surprisingly from retrospective, but it worked, worked well and was still much cheaper then going Native.
But then we got to signing functionality. It was way too slow through WebView layer. But impossible is nothing! We implemented it in Java, the Native way, and injected into the hybrid part of application. And everyone was happy ever after :)
I love this example as it shows how combining different technologial approaches may benefit the final result. For more details you can follow this link.

An ELEKS' Responsive Web Site

Recently our marketing department together with UX department had a great challenge to showcase our expertise in Web Design and Web Development by redesigning our own web site. The main priority of course was the quality of the result. We knew that we will update the content frequently, that we want to reach as wide audience as possible, that all we want is to present information, not to interact with users. So it was clear that we don't need an app, and it was clear that we don't want two separate websites. We wanted responsive. And, in my humble opinion, as a person who didn't participate in this project, the result is awesome. Oh, yes, it's not just my opinion, we won quite nice awards for this work. Here's a nice interactive case study explaining how me made it.

That's all, folks

I was very happy to share this knowledge with you, and I'd be even more happy with comments/critics/discussions on this topic. Feel more then welcome to contact me at markiyan.matsekh@eleks.com and stay tuned for more interesting articles on elekslabs.com. I'm planning to release research articles on Enterprise Mobility, Xamarin, and Wearable Technologies in not to distant future.

PhoneGap: An Unexpected Journey

This is a story of a web developer, who's a complete newbie in mobile world and who were given a task to research and develop a tablet application from scratch, re-using his experience in web technologies, i.e. using PhoneGap.

So, my friend, if you are like me - go on reading. This article will give you an intensive look at what PhoneGap is from a perspective of web developer.

Part 1. Theory

Chapter 0. What is PhoneGap?

I suppose you all have an idea of what it is, but I'd like to stick to a definition and point out couple of things. So, as they say,

PhoneGap is an open source framework for quickly building cross-platform mobile apps using Html, Css and JavaScript. 

And it is true(to certain extent). Lets take a deeper look:

Open Source - yes. you can delve into implementation details and even fix their bugs if you want to. But I wouldn't recommend doing so.

Framework - as you will see later, PhoneGap is just a little piece of javascript and platform specific language. There's not much mystery in it.

Quickly - this really depends. Read further to see the answer.

Cross-platform mobile apps - this is the thing that brings attention of clients and managers. It seems that you can simply write your code once and run on any device, saving tones of time and money. Unfortunately the truth is not so astonishing.

Html, Css and JavaScript - yes, yes and yes! we're here because of these cute little guys:) I personally love'em and was very glad to know that I can use them in mobile world.

Chapter 1. Origin

Anyway, how and why did people end up with a product such as PhoneGap? This is a nice one. Here the creators talk about their beliefs and, I must say, they are pretty original. Like these two:

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

As you may know, PhoneGap isn't the only tool that allows similar functionality. And there's a lot of noise about how these tools work(like this one) and I must say it looked like magic to me for a while. Honestly, I was a bit disappointed...but more on this later. Lets talk about more obvious things first.

So, we have our small html website. And we want it to become a mobile app. Also, we want it to use specific device feature, let it be camera. Where do we start from?

First, we need something to run our site, parse html, translate/compile js etc. In web we have browser. What do we have in mobile app? As you may know, a mobile app is just a piece of executable binary code, which special device knows how to behave with. But our web site is a piece of text! My iPhone doesn't know how to run it as app! The answer is WebView(the name depends from platform). So what is it? 

A WebView is kind of a built-in browser, that can be embedded into a mobile application and which knows how to run html-based web sites. Every platform has its own implementation of WebView, for example on Android you have android.webkit.WebView class, on iOS you have UIWebView, on Windows 8 you have 

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.

So, first problem solved - we have our runtime environment. But how do we access a camera? None of popular web browsers has provided us with stable version of camera API, so it is doubtful that some built-in ones will. This is were tool like PhoneGap comes in handy. It gives you a javascript file which has declaration of pure js methods, which know how to access device's features. All you have to do to use it - is include it as a script in your html file, and voila!

Chapter 2.5. Implementation. Learning the Magic.

But for me this was still not enough. This place seemed like the most magic for me. How can javascript access native features, if on exact platform you have special language-specific API for that? Is there some kind of js-to native code translator? But how does the runtime translate js calls into Java code? into Objective C? And back?

Now, sit down kids, and listen carefully, as we're going to learn some magic!

First let me say - kudos to people who implemented PhoneGap, for their creativity and braveness.
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.

Prompt

On Android, in WebChromeClient class, there is a way to intercept javascript's prompt message using method onJsPrompt from Java. This gives us a flat-footed way to send messages from js to Java and back(here it is).

You can also find an extended non-PhoneGap related sample here.

"WAT? This ain't magic, Gandalf!" - you say, and I would agree with you. Let's move on. But just let me enjoy this piece of comment with you

Since we are hacking prompts for our own purposes, we should not be using them for this purpose, perhaps we should hack console.log to do this instead!

Perhaps, you should!

JsObject

The WebView class exposes method addJavascriptInterface which lets you bind js calls directly to Java calls, with just a couple of conventions. This looks more right, as for me. Why didn't they use it all the time? well, here's a complete answer I guess. To wrap up - couple of compatibility bugs, as I mentioned before.

So, one could say - we solved the problem. We have runtime, we have communication with native API...did we miss something? Yes, performance. Most operations require some time to execute, and we don't want our GUI to freeze. That's why PhoneGap supports asynchronous model of communication. And as you can guess this creates some obstacles. How should we send messages back from Java to Js? 

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.

OnlineEvent

As some of you may know, there's a thing called Online/Offline event in html5. Basically it's a way to tell your js code that user's device have connected/disconnected from Internet. I'm not sure if all browsers have agreed on the API yet, but there have been some efforts. Anyway, our lovely PhoneGap found a good use for this event! You getting there? Yes!

Bingo! Hack in a pure form:)

So, to sum up, PhoneGap has lots of ways of communication between native and js sides, each for a specific platform/version/situation. It is so, because mobile vendors didn't have an intention to let this happen on every platform same way. And this is what PhoneGap was meant to do. So this is the core part, and I must say, they wrapped the dirty job pretty good, so that the upper level doesn't have to worry about these details.

Chapter 3. Architecture

Generally speaking, PhoneGap has a plugin-based architecture. Each device-specific feature is a plugin, which consists of javascript and native sides. Js side should be as cross-platform as possible, whereas native side can be implemented only once, for 1 device. Nevertheless built-in plugins are developed for all of the most popular platforms, so no need to reinvent the wheel. I'm not going to tell how they should be built - there are tones of guides for this. 

What I would like to say is that this architecture, together with open source code, not only allows you to fix their bugs, but also allows you to tweak their plugins for you needs. And you can also built your own plugin, and support only on the platform you want. Maybe somebody will extend it to his needs. Maybe you will extend somebody's plugin for you platform. This approach makes Phonegap a very fast-growing and powerful community. Well done!

So, enough theory - let's feel how is it - to develop a mobile app with PhoneGap!

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, first thing I done - went to official PhoneGap "Getting Started with Android" guide, which seemed like a perfect start. Oh, how far from essence was I...

After several hours of pain and suffering I found out that I was not the only one having problems with installation. As it turned out - there was a lot of tiny typos and mistakes in that guide(on Windows only, as they all seem to work on Mac), which a non-mobile developer wouldn't notice.

Important thing I realized is that most of the errors I got was Android-specific, not PhoneGap-specific. In Android context, PhoneGap is just a Java library, and piece of static contents - html css and js. All you need to run PhoneGap app when you have working android environment is to include this library in project and include js script in your static web-site.

Of course, in PhoneGap docs they should've warn web-developers about common pitfalls of installing Android environment, and test their guides better. But don't be angry at them - be angry at Android:)
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

And so I ran my "Hello, World!" with PhoneGap.
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?"
WRONG!
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

Here I've got the bad news guys. There's no way to debug javascript code inside an app on a device as you've got used to. No f12, no f8, no "debugger;". But, everything's not lost, there are several ways to diagnose the problems.

debug in browser

It's not universal, but for debugging purposes you can open you app in browser and use beloved js debugger to find the problem. Although all phonegap-specific features won't work of course. It's not always easy to maintain your app both for device and for browser because of these things. Usually this approach is good at the beginnings, when you're building your main logic without dependencies on device-specific features, or when you're editing something unrelated to device.

console.log

PhoneGap environment gives you a way to transport debug messages from js to your Eclipse console via console.log() method.Although it's not a run-time debugger, this can come in handy sometimes. 

hehe, good old way, reminds me of debugging scripts on ie6. Code speaks of itself

weinre

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.

In mobile world people use things like AppStore and Google Play to download apps. And while putting an app to Google Play is pretty easy, AppStore may reject your app if it doesn't follow their guidelines. Knowing them and following them is another problem, but there's a conceptual concern going on on the internet about PhoneGap and AppStore. 

PhoneGap and AppStore

Thing is, one of the rules of AppStore is that you cannot use UIWebView to load remote website, as AppStore cannot control the content of this website and you can post whatever you want on it, including forbidden stuff. This takes us to a fair question - if PhoneGap is the website inside UIWebView, will AppStore accept our app?

The answer is not just yes or no. As PhoneGap officially says, apps built on PhoneGap are not banned on AppStore. Actually it makes sense, as PhoneGap app is not a remote website, but a local one and you cannot dynamically change its contents without going through AppStore. But this is not the final point. You sill have to follow Apple's guidelines. Apple has made a good clear statement about this:

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.

PhoneGap Build

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.


Another thing is that these browsers are usually slower. Why? Well, for example, on iOS Safari uses Nitro to compile javascript, which dramatically improves performance, but on built-in browser Nitro is turned off for security (and i guess political reasons). This was one of the reasons why facebook moved from html to native approach(btw here's a cool video about that).

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.