PhoneGap

I’ve been wrestling with this question for some time, and I thought this post may help sort out my thoughts and opinions while giving you some important insight. Are hybrid mobile apps going to become the developer’s choice anytime soon? The debate can be pretty heated as companies choose one technology over the other.

Hybrid, the Unlikely Union

Let’s get the definitions straight before we begin. A hybrid app is one of those mobile apps that uses a native web view to display HTML, CSS, and JS “web” apps. They’re only sort-of “web apps” because they are run locally, though they often pull data from online sources via AJAX requests. So, you have this HTML/CSS/JS app running inside of a natively-compiled stand-alone web browser of sorts on your phone. One such example is PhoneGap. Because the logic bits of the app are written using web technologies, you can often develop once and deploy on multiple platforms, so long as you’re using supported markup. You’re killing multiple birds with one stone.

Hybrid is the Bee’s Knees

As I mentioned above, hybrid technologies are great for developing cross-platform apps. Seriously – since iOS, Android, and even some Blackberry devices are both running Webkit most, if not all, your html, css, js is going to work remarkably similarly on both platforms. It’s pretty enticing. From your and your client’s perspective it’s a pretty easy sell. For one round of development you have the potential to hit many more users. It’s pretty cost-effective. Pretty soon you’re singing the praises of your decision and you’ve decided that from now on hybrid apps are the bee’s knees.

I have a confession – I’m a console logging junkie. I just like to see what’s going on. While that may be great for development, at some point you’ll have to quiet the logging down for production. Really – doing enough logging will slow everything down each time you’ve inserted a console.log() into your code.

Silencing the output to XCode’s debugging console wasn’t immediately obvious. Overriding console.log() in JS by setting it to an empty function worked in the browser for development, but as soon as I loaded the app onto the actual simulator, we were back to square one. Enter the PhoneGap DebugConsole prototype. Override it.

There’s been a bit of confusion surrounding changes to XCode4 and PhoneGap. Right now the big ones are 1) Where did my PhoneGap user templates go!? and 2) How do I submit my PhoneGap-based app to Apple? Let me help you.

1) You want to create a new PG project, but you’re not seeing the XCode templates when you go through the new project menus. Check out Shazron’s blog @ Nitobi for a command-line script to get you a new project up and running. It’s not as sexy as the XCode template, but it will do.

2) You can’t compile your app for submission to Apple? That was a little more tricky to track down. See this thread on the Apple Dev Forums for a bit of an abstract view of what’s going on. I’ll save you the details. Follow these steps to XCode bliss.

Select the PhoneGapLib.xcodeproj entry in your files list:

Make sure the “All” tab is selected:

Look for the “Deployment” section and scroll down until you see the “Skip Install” parameter. Set Skip Install to YES:

EDIT: Make sure to verify your target device…
Make sure you have the “iOS Device” option selected in the schemes drop-down:

Go over to the “Product > Archive” menu. XCode will do its compile magic. Open the Organizer to see the app and the listed archives when the compile is complete. At this point, make sure you are ready to upload the app to iTunes Connect. Bonus: we get to skip the Application Loader app from now on!

Select the archive and click the “Submit” button. XCode will ask for your credentials. Log in and select the appropriate app and distribution profile from the list. Submit. If all goes to plan, you’ll get a message of approval. Finished.

This little bit of code is going to be useful to those of you developing a “singe page” app inside of PhoneGap. This applies to Sencha Touch (big fan), but doesn’t as much to jQuery mobile and jQTouch, as it’s a multi-page/navigation based event framework (it uses the app’s url string to do things like move around to different link anchors). This is really important on these single page apps because the Android hardware back button will send the PhoneGap app to the background. You need some way to intercept it so you can start building your own history management mechanism. Sounds fun, right? It’s actually not that hard.

On app initialization, add an event listener for Android’s back button, and the callback to handle it. PhoneGap takes care of the interface between Android and your app.

Swift

1

2

3

4

5

document.addEventListener("backbutton",backKeyDown,true);

functionbackKeyDown(){

// Call my back key code here.

alert('go back!');

}

That’s enough to get you started, and it should be pretty apparent if it works or not.

How about history management? It will depend on the app and what makes sense, BUT you’ll probably want to create a history array, and pop off some value that directs the app each time you hit the hardware back button. Here’s another idea: change the destination of the back button depending on the view. I personally like the idea of the latter because apps built on Sencha Touch are going to have easy tie-ins through predefined listeners JS Objects that define screen elements like buttons.

Getting close to finishing up an app for a client in the coming weeks, my business partner and I decided it would be a good idea to include some analytics code so we could track how people are using our application. We ended up using Pinch Media’s Analytics to do our tracking. It came down to this: their code is REALLY easy to implement, and they provide us with just enough information to satisfy our curiosity. I think one of the biggest draws is that it records information regardless of the user’s online status – meaning offline app usage information is stored to a small database and then uploaded once the user reconnects. Had we used a web-based solution, which would have been natural given the nature of PhoneGap (the underpinning of our application) being UIWebView, we would have missed out on some details without considerable work-arounds to cache data as Pinch Analytics does.

Because PhoneGap is essentially a single view application that displays web pages, you are a bit limited with the extent that you can integrate Pinch Analytics out of the box… unless you use javascript callbacks to Objective-C within PhoneGap. That’s not the point of this post. The point is that you just need to follow Pinch’s instructions and you will have analytics data reported back to you within a few hours.

Moving forward, I’m likely to investigate some of the finer points of creating my own PhoneGap callback functions so I can embed Pinch Analytics Beacon methods, which are nice little ways to record information about discreet actions taken within your app – recording leader board views, for example.

I recently ran across some major performance problems with a jQTouch app running in PhoneGap. Some of the symptoms included long pauses on touch events, non-responsiveness, and laggy transitions.

Brian LeRoux (Nitobi/PhoneGap), Jesse McFayden (Nitobi/PhoneGap), and David Kaneda (jQTouch) were the stars looking into this issue. Ends up Jesse found where the Accelerometer was taking a 40Hz sample rate and sending the data to a callback. The solution is to just disable Accelerometer use – either in the plist or, as I did, comment-out all the accelerometer bits. Likewise, I removed location functionality, as this app in particular doesn’t need it.

You can read Jesse McFayden’s post here. And if you’ll excuse me, I have an app to finish…