Monday, May 09, 2011
GQueues Mobile: a case for the HTML5 web app
By Cameron Henneke, Founder and Principal Engineer of GQueues
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
With the proliferation of mobile app stores, the intensity of the native app vs. web app debate in the mobile space continues to increase. While native apps offer tighter phone integration and more features, developers must maintain multiple apps and codebases. Web apps can serve a variety of devices from only one source, but they are limited by current browser technology.
In the Google IO session HTML5 versus Android: Apps or Web for Mobile Development?, Google Developer Advocates Reto Meier and Michael Mahemoff explore the advantages of both strategies. In this post I describe my own experience as an argument that an HTML5 app is a viable and sensible option for online products with limited resources.
Back in 2009 I started developing GQueues, a simple yet powerful task manager that helps people get things done. Built on Google App Engine, GQueues allows users to log in with Gmail and Google Apps accounts, and provides a full set of features including two-way Google Calendar syncing, shared lists, assignments, subtasks, repeating tasks, tagging, and reminders.
While I initially created an “optimized” version of the site for phone browsers, users have been clamoring for a native app ever since its launch two years ago. As the product’s sole developer, with every new feature I add, I consider quite carefully how it will affect maintenance and future development. Creating native apps for iOS, Android, Palm, and Blackberry would not only require a huge initial investment of time, but also dramatically slow down every new subsequent feature added, since each app would need updating. If GQueues were a large company with teams of developers this wouldn’t be as big an issue, although multiple apps still increase complexity and add overhead.
After engaging with users on our discussion forum, I learned that when they asked for a “native app,” what they really wanted was the ability to manage their tasks offline. My challenge was clear: if I could create a fast, intuitive web app with offline support, then I could satisfy users on a wide variety of phones while having only one mobile codebase to maintain as I enhanced the product.
Three months ago I set out to essentially rewrite the entire GQueues product as a mobile web app that utilized a Web SQL database for offline storage and an Application Cache for static resources. The journey was filled with many challenges, to say the least. With current mobile JavaScript libraries still growing to maturity, I found it necessary to create my own custom framework to run the app. Since GQueues data is stored in App Engine’s datastore, which is a schema-less, “noSQL” database, syncing to the mobile SQL database proved quite challenging as well. Essentially this required creating an object relational mapping layer in JavaScript to sit on top of the mobile database and interface with data on App Engine as well as input from the user. As a bonus challenge, current implementations of Web SQL only support asynchronous calls, so architecting the front-end JavaScript code required a high use of callbacks and careful planning around data availability.
During development, my test devices included a Nexus S, iPhone, and iPad. A day before launch I was delighted to find the mobile app worked great on Motorola Xoom and Samsung Galaxy Android tablets, as well as the Blackberry Playbook. This fortuitous discovery reaffirmed my decision to have one codebase serving many devices. Last week I launched the new GQueues Mobile, which so far has been met with very positive reactions from users – even the steadfast “native app” proponents! With a team of developers I surely could have created native apps for several devices, but with my existing constraints I know the HTML5 strategy was the right decision for GQueues. Check out our video and determine for yourself if GQueues Mobile stacks up to a native app.
Come see GQueues in the Developer Sandbox at Google I/O on May 10-11.
Cameron Henneke is an entrepreneur based in Chicago who loves Python and JavaScript equally. While not coding or answering support emails, he enjoys playing the piano, backpacking, and cheering on the Bulls.
Posted by Scott Knaster, Editor
Subscribe to:
Post Comments (Atom)
Why is this guy not working at Google?
ReplyDelete+1
ReplyDeleteHi gqueues, you didn't show the asking msg "create Db size 10mb" local device in your demo screencast? What wiill happen that Db, if I don't want to use your app! May be a bit of silly ques! Much appreciated your ans?
ReplyDeleteHi Thura - If you no longer want to use the app you can delete the database from your phone. Directions here:
ReplyDeletehttp://www.gqueues.com/help/mobileOffline#resetting
have you considered building this with phonegap? then you could put it in the appstore/marketplace and it would be easier to find. might even run a bit faster.
ReplyDeleteHmmmm I logged in into gqueuses using my google account... Now I want unautherize gqueuses to use my google account but can't find anything about gqueuses @
ReplyDeletehttps://www.google.com/accounts/IssuedAuthSubTokens
BLEH!!!
We need the native android or iPhone apps.
ReplyDeleteThe gqueues HTML5 mobile browser-based app is not a good counterpart to their excellent desktop browser version.
This comment has been removed by the author.
ReplyDeleteI found the Inbox.
ReplyDeleteI am using a Droid 3 and neither the native browser nor dolphin browser passed the test. Do you know which browsers will work?
ReplyDelete