If you are like me
you want to maximize the market for your mobile software. Well,
PhoneGap coupled with the build.phonegap.com SAAS is the bomb for that.
With PhoneGap you can leverage your web development experience and the power of
the W3C standards and HTML5 to, as Adobe advertises, "create mobile apps
compile them for multiple platforms in the cloud.” My app, which I called the DATA-EASY Field Data Collector, does
that. Night and day for months now, I’ve
drank gallons of the PhoneGap and build.phonegap.com Kool-Aid as to master the mobile
device's camera, GPS, file system, in-app-browser and other technical
nightmares on three of those platforms, iOS, Android and Windows Phone. In
the beginning I made an HTML application, uploaded it to build.phonegap.com and
I got back native platform install packages for iOS, Android, Windows Phone,
Blackberry, WebOS, Symbian and Bada. I thought
“Brilliant!”, and it is. If you have worked
with the vendor specific mobile APIs such as the iOS API and Android API you
understand just how amazing that truly is.
Was it easy? Well, yes, if your app
is simple it is easy. However, my App is
not simple so a short time later I ran into my first issues. At the time I was drunk on the Kool-Aid and
reluctant to give up on the quest for a true cross-platform Mobile App Utopia. It is a fact that PhoneGap does a pretty good
job of isolating your application from the mobile platform battleground with it’s
numerous core plugins, but still there will be collateral damage when you get
involved, you just can’t avoid it. There is not a tool in existence that can
completely shield you from the turmoil of emerging and rapidly changing Mobile App
and Web standards, including PhoneGap.
So if you must go down this road, be prepared to deal with the pain of
battle, it is still raging.
I could go on and on
about the individual issues I encountered due to Mobile platform and HTML
browser differences ranging from support for Indexed DB storage to handling
files and HTML multi-part responses, but I got past those with many late nights
and weekends. So, instead I’ll focus on
the latest struggle I am experiencing with what I call “the Gap in PhoneGap’s Last
Mile” because that is the one we should all be most concerned about if we want
to build a true commercial mobile application.
Build.phonegap.com lulls you into believing your hard work is safe and
secure, but don’t make that mistake like I did.
Just because you get back install packages from build.phonegap.com does
not mean those packages will run and deploy easily, and perhaps not at all. First, it takes work and skill to find ways
to test those packages on emulators and mobile devices. The first suggestion I will give you is don’t
even bother with emulators. I’ll just
leave it at that. I wasted a lot of time
there. Go out, beg, borrow or buy the mobile devices themselves and deploy the
packages and test them on those devices.
In my case I owned an iPad 3 and Android Samsung S4, and I borrowed a
Windows 8 Phone from my son. Next, get
good with Open SSL, I posted a couple of other blog entries with some tips
there. You can build and test an Android
app on your Android devices without a certificate, but that is not the case for
iOS and Windows Phone. You will need to
use OpenSSL or something equivalent to generate the encryption keys and certificate
requests required to build and deploy the iOS and Windows Phone apps. At first I was able to accomplish all of that
on my Windows 7 computer, but recently ran into issues there, perhaps due to
the Heartbleed bug in OpenSSL. I worked around
that issue by renting a Mac from MacInCloud.com and using OpenSSL on the Mac to
generate a key and certificate request for the iOS deployment. Be aware you might have to do the same. Also, you will have to pay money (about $100
each) to Apple and Microsoft if you want to test your install package on your
devices. They require each device you
want to run your tests on to be registered with your “developer account”. Again, Android has no such restriction
there. At first I had no Windows Phone
so I just used my Windows 7 PC to get all the way to the deployment of the
Android and iOS build packages on my devices.
That actually went pretty smoothly.
I got the iOS certificate and registered my iPad with my Apple Developer
Account and used the QR scanner interface of build.phonegap.com to deploy both
the iOS and the Android apps. Again, it
worked brilliantly, this is easy, I thought.
In fact it was so easy and brilliant I refused to give up when I
encountered shortcomings such as:
There is no step through debugger to step
developing COBOL on mainframes, before debuggers were common, to survive that. Not fun.
Though the core plugins, such as the file
system plugin, appear at first to work the same on the different devices, they don’t.
PhoneGap plugins help with standardization,
but nothing can shield you from the fact you are running in an HTML browser web-view
and those browsers are still very different from one platform to the next. Bootstrap goes a long way there, but not all
can entirely rely upon. As you try to
come up with a solid design you will feel like you are walking through a
carnival with the carnies yelling “come on over here buddy, you’ll win big with
Javscript itself has issues, big ones. If you are coming from a compiled,
object-oriented environment like I did, be prepared to be astounded by the... let’s
call it “flexibility”. I’m used to it
different mobile devices, was unimaginable.
Ok, I know I am being
overly dramatic, but the fact is I was overdosing on caffeine and skipping
showers for days to get through the development and testing phases of the first
two platforms, iOS and Android.
Now that brings me to
Windows Phone. I’m tempted to say don’t
even go there. I don’t think Microsoft
wants you to go there. First, I faced
the challenge of getting the .xap from build.phonegap.com onto my son’s Windows
8 Phone. Well I may not have found the
only way to do it, but here’s how I did it.
There’s a Windows 8 SDK with a command line deployment tool that does
it. The problem is it only runs on
Windows 8. So, off to Best Buy I
went. Actually I needed a new PC badly
and I could find no way to accomplish Windows 8 Phone deployment without
Windows 8. First I installed the latest
Visual Studio Express 2013 release 2.
After a few days of monkeying around with the emulator and Hyper-V (I
really wanted Hyper-V to work but couldn’t get there with my Acer. Uninstalled
McGaffe, etc. etc. That’s another blog
entry in itself.) I finally resorted to
plugging in the phone and running the command line tool from the SDK. The problem was the SKD was for Windows Phone
8.1 not 8.0 and it did not work. I
figured, well I’ll upgrade my son’s phone to 8.1. It turns out Windows Phone 8.1 is not
released yet and I no longer have an MSDN subscription so I couldn’t get there
from here. Finally I gave up and installed
Visual Studio 2012 and the 8.0 Windows Phone SDK, registered the phone with my
new Windows Phone Developer account and got it running, sorta... Remember, no
step through debugger, different browser (IE 10) the horror, the horror.. At least
I could still use Weinre to get to the bottom of some of the issues, wrong! As
of today the Windows Phone connects to the Weinre server for about thirty
seconds and then disconnects. It is a
known issue I could not work around. In
the end, see below for the list of issues I opened up on the Apache Cordova Project
(the source of the core plugins for PhoneGap).
I actually found
work-arounds for most of the issues, most of them related to the way files and
directories are handled differently and the way URIs and navigation works. I’ll just say at this point stay away from
using hrefs to navigate the app. Several
of the navigation / URI problems I found were more to do with AngularJS than
with PhoneGap, so if you use something other than AngularJS you might not have
as much trouble. In hind-site, I suggest
you stick with jQuery Mobile and avoid AngularJS, Bootstrap and Dojo if you
want to deploy to all three platforms. They
are all very good in their own right, but I lost a HUUUUGE amount of time working
around issues with those. In the end, my
App is running on Windows, except for one of the key components. I implemented the Google Drive API and it is
a keystone to the app. Not surprisingly
the App bails silently whenever the Google Drive API loads on the Windows 8
Phone. Without a debugger I still have
no idea why. So I put in another twenty
hour day yesterday trying to port all that code to the Windows SkyDrive
API. So far no joy there. Both APIs rely on OAuth which relies on the
in-app-browser plugin which I think is not working properly on Windows at this
time. Again, it is very hard to pinpoint
with no debugger.
Oh yeah, back to the topic
of this blog, “the Gap in PhoneGap’s Last Mile”. So what I am referring to is I was lulled by the brilliance of build.phonegap.com into thinking deployment to the three mobile platforms was going to be easier that it is. In fact, the last phase, deployment to the App Stores, was nearly the thing that shot down months of hard work. I know it is not PhoneGap's fault these App Stores do business the way they do, but it should be more clear that having a "built", "deployable" file is a long ways from getting the App tested and distributed. Also, the development process is deceptive because you have "built", "deploy-able" files from build.phonegap.com right out of the starting gate. However, over time as the App becomes more sophisticated you realize you have to invest a huge amount of additional effort to account for the differences in the browsers, file systems and other platform specific things that the plugins don't handle that well. I started by developing each feature and testing it on Android. After it worked well there I would install it on iOS. Usually that's where the real work began. I ran into several issues reading and writing files and converting to and from binary and base64 on iOS. I ran into other issues going from iOS to Android with the database behavior since iOS supported IndexedDB, but Android did not. Those discrepancies caused me to re-factor code I had working on one platform because it would not run on the other. Compounded by the lack of a step-through-debugger, the development process gets harder and harder, and that is not even considering the Windows Phone, it gets even more difficult when that one is thrown into the mix. At this point the open-source-ness is good, but I would be willing to pay more for more help / support / documentation and features. For example, I would certainly have paid something if build.phonegap.com offered to broker the App Store submissions for me. So in conclusion, you can get a PhoneGap App running on iOS and Android quickly, but you will learn you are on your own getting the App that last mile from there up to the App Stores, and it is a very loooooooooong mile..