BikeNavApp

(From Klos Komedia) I have been intrigued by mobile application development ever since working on my thesis in 2006. Lots of time has passed and so much has changed since then. 5 years back, I had to revert to J2ME to get an application working on a Nokia Series 60 phone. These days, I can use HTML5 (in conjunction with PhoneGap) to deploy a native-like application to the Apple App Store to offer it on the iPhone market. However, it was important to me to pick an application that I would use personally and so I came up with BikeNav, the route planner for your next bike ride to work, to shop for groceries or to visit a friend.

What is it?

I really like to use my bike as a clean way of transportation but when going from A to B by bike, it is especially vital in car-dominated USA to pick a route that preferably has some sort of bike lane in order for the cars to give you some space or where the speed limit is at a reasonable level (i.e. residential streets). The native map application on the iPhone already has routing functionality built in for public transport, walking and when driving with your car, but not for biking. Interestingly though, the desktop version of Google Maps has this functionality (launched in March 2010 for several cities in the US and Canada). So in order to fill this gap, I had the idea for BikeNav, which uses this Google Maps functionality to give the user the most bicycle friendly route from A to B.

Further details about the features of the application as well as screenshots can be found on the App Store as well as on my support page. Below I will focus more on an overview of the technical implementation of the application.

The Tech

After looking into Objective-C and native iPhone development, it became clear to me rather quickly that I should stay with what I am good at, meaning web development technologies. Objective-C as well as how all the different pieces fit together in XCode was just hugely confusing, which made me decide that if I can somehow use web technologies to achieve what I want then I am certainly going to go for that  .

jQuery Mobile

I had to do some research at work on Mobile JavaScript Frameworks and looked into two of them that got mentioned quite a lot: jQuery Mobile and Sencha Touch. I had never really worked with jQuery and Sencha was completely new to me, but looking at jQuery Mobile, I realized that it might give me more freedom than Sencha with regards to being able to easily style and access the interface elements that I needed for the application. The only downside I could see was that, at the time, it was in Alpha 1 release, indicating that there might still be some bugs (which turned out to be true and I had to work around them while developing). As of this writing, jQuery Mobile is now in Alpha 4.1.

PhoneGap

Because I wanted to deploy my application on the Apple App Store, I had to find a way to somehow turn my mobile application into a native(-like) app. PhoneGap to the rescue. PhoneGap gives the developer the ability to wrap a web application (written in HTML, CSS and JavaScript) into a native shell that gives it the needed characteristics in order to push it to the App Store, the same way as you would if it were an Objective-C application. In addition, PhoneGap provides a JavaScript bridge, that lets you access native device capabilities (i.e. access to the contact list on the device) from within your application using JavaScript.

Lessons learned and “What’s next?”

Initially I made the decision to go with jQuery Mobile because I felt it would give me more flexibility with regards to being able to easily build up my interface elements, since the framework lets you build a mobile web app very much the same way you would build a web site or web app for the desktop. With Sencha Touch, it seemed that it would have been more difficult to come up with a non-standard interface (like I wanted to use) for my app, since all the control is in JavaScript, with very few things defined in HTML and CSS. Alternatively, I probably could have used Titanium as well, but again, I felt it would have been more of a challenge to get the positioning and styling of all the elements the way I wanted it—since Titanium also has an ‘all JavaScript’ approach.

Adopting early has its downsides

As I mentioned earlier, the slight downside to using jQuery Mobile was (and still is) that it was in an early Alpha release. I actually started developing with Alpha 1, meanwhile it is in Alpha 4.1. I only tried to upgrade once, about half-way through development, and noticed that lots of things had been broken by the update. So I reverted back to Alpha 1, and worked my way around the bugs and the missing features that just weren’t there at the time. Since I would like to also offer the application on Android phones at some point, I need to upgrade eventually, but I think I will wait until the framework is at least out of its Alpha state.

Bridging the gap

I am, however, very pleased so far with PhoneGap. Getting it installed was easy and building the application out of XCode code is very straight forward as well. All I had to do was copy my HTML, CSS, JavaScript and image files into the www folder of the project and hit ‘build & run’. Granted, I am not using the PhoneGap JavaScript bridge in this application to access native device features (yet) and I also haven’t used PhoneGap for building BikeNav for Android (yet), so there might be potential hurdles to overcome in this regard. But from what I have seen so far, the combination of jQuery Mobile and PhoneGap works very well for me.

In terms of new features, I would love to do some research on what options there are (if any) to do ‘text to speech’ in JavaScript (for reading out driving directions) as well as integration of Google Street View images into the application. from klauskomenda