Mobilizing DrupalCon Chicago

by Larry Garfield

With the dust settled and results tallied, we finally have time to look back on DrupalCon Chicago and all the work that went into it. And much work there was! The whole team did an amazing job, and I'm proud to have been a part of it.

One place in particular that we broke new ground, at least for us, was the DrupalCon Chicago mobile app. Chicago was not the first DrupalCon to have a mobile app, but it was the first to have a fully cross-platform application for both of the dominant mobile platforms, iOS and Android. With the immense surge in popularity of Android in the past year and the continued strength of iOS supporting only a single mobile OS would not have been an option.

screenshots of the DrupalCon Chicago app

At Palantir, we've discussed working on mobile apps on and off for some time but never had a client who was sufficiently interested in one. The DrupalCon Chicago leads, though, were sufficiently interested (and also happened to be my bosses). At the same time, Pat Teglia had recently joined the Palantir team and had been experimenting with mobile development on his own. Jen Simmons, also a new Palantiri, was eager to try her hand at designing for a new environment. And although it's been a while, I used to be a mobile developer back when Palm OS 4 was still considered cool. (I know, back in the dark ages.) It was an ideal combination, and while the end result wasn't everything we hoped for it was a qualified success.

Building the app

Of course, none of us wanted to try and co-develop a Java app for Android and an Objective-C app for iOS at the same time, so we needed a cross-platform framework. After some research late last fall, we settled on the Appcelerator Titanium framework. Where most cross-mobile frameworks are essentially window-dressing around embedded HTML5 Web pages, Titanium uses pure Javascript as a cross-platform API using a custom VM (much the same way that Java on the desktop uses a separate VM on Windows, Mac, and Linux to translate code into native API commands). That resulted in a much more traditional "application-esque" workflow, as well as access to far more native functionality and UI elements than an HTML5 app. Most importantly, it gave us significant built-in offline storage capability with an embedded SQLite database. This enabled us to cover the Android 1.6 local storage gap that still existed in November when we started.

We knew from the beginning that in order to be successful, we would need to integrate the app with the DrupalCon website. Most importantly, we wanted to be able to pull down session and presenter content from the site on the fly so that attendees always had the most up to date info (especially regarding schedule changes). Although other sites have built Titanium-based companion apps before, none of them have resulted in a reusable Drupal-centric library. Our first task, therefore, was to try and build one that we could use and then release.

That turned out to be a double-edged sword. On the one hand, it resulted in a fair bit of overly-generic code that we didn't truly need for this app and didn't even end up using. On the other, some of that extra flexibility ended up saving our bacon later on when we needed to work around some bug in Titanium or inconsistency in Drupal's output. Most notably, it included a partial port of Drupal 7's database layer to Titanium in order to support the dynamic queries we needed to handle.

Originally we intended to use the Services module to authenticate users against the site and then download complete session nodes to the app. We soon realized, however, that not only would that be inefficient (there were a lot of session nodes) it wouldn't give us complete data: Much of the data about a session was spread out across dependent Room or Time Slot nodes, as is quite common in a modern Drupal site. Instead, we dropped Services and switched to the Views Datasource module, which let us use Views to generate fully-filled-out pseudo-nodes that we could download as JSON in a single HTTP request. That had its own challenges, most notably inconsistent JSON structure and a misuse of Views' display plugins, but fortunately we were able to work around those thanks to the extra layers we had built into our library code.

In the end, we were able to allow the user to refresh their data at any time from the site with only a single HTTP request, and then slice and dice data however we needed to for display. We went through a couple of different iterations on the design before settling on the layout we shipped with, actually, and scaled back some portions after realizing that we wouldn't have time to build. Having all of our data on-demand with a clean way to rebuild and reindex it made it easy to vary the application as we evolved the design.

The other major feature we managed to sneak in at the last minute was the ability to review sessions direct from the phone. Given the importance of evaluations in helping future DrupalCons pick good presenters, we wanted to make that process as easy and painless as possible. Rather than duplicate functionality here, we simply directed the user to an embedded browser within the app that pointed to the evaluation form on the web site, complete with custom CSS to make those pages mobile friendly. We even managed to sneak some improvements into Bakery in order to streamline the login process. (To be more specific, the nice folks over at GVS did that for us.) While not as slick as we'd hoped, it was still faster than trying to authenticate via Services and then recreating all of the form functionality in the app.

Fun with stats

The week of the conference, we had approximately 2,000 downloads, which was about 2/3 of attendees. Most were from the USA, of course, but a few were scattered across Europe, Asia, and Australia. Titanium's embedded statistics reported that the app was started some 12,000 times, with an average of 6.5 sessions per user. Hopefully at least 10,000 of those were enjoyable experiences...

What we found most interesting, however, is the platform-specific stats. Not surprisingly, given a typical Drupal audience, iOS downloads outnumbered Android downloads 2 to 1, even though Android has a slight lead in the overall market. Android users, however, apparently used the app twice as much as their Apple-using counterparts. I cannot speculate as to why that is (although you're welcome to do so in the comments), but we found it fascinating.

Certainly one thing is clear: Future Drupal events that decide to go mobile cannot afford to ignore either platform. There are lots of mobile Drupalers, but they're rather heterogeneous as to their platform of choice.

Reflection

The feedback we received on the mobile app, both in person and via the Apple App Store and Android Market, was overall very positive. The biggest complaint people had was the lack of a "my schedule" feature in the app. We actually considered that a good sign, as we had wanted to build that feature in. Why didn't we? Mostly we ran out of time, and only wanted to build it if we could do it right. By "right", we meant integrated with the session flagging on the DrupalCon site itself. We decided that it was better to not have two disconnected personal schedules so dropped that feature, but we'd love to see a future conference finish that off. (The Services integration needed is already partially there.)

Both platforms had their challenges, however. For Android, the available emulator is surprisingly slow. The process of compiling and testing the application on the Android emulator was far slower than with the iOS Simulator, which for a team used to instantaneous feedback from a Web script was a challenge. We frequently found ourselves doing primary development with the iOS Simulator and then testing periodically on the Android emulator, simply for time reasons. Whether that is due to Android, Titanium, or both we aren't sure.

For getting the code onto actual hardware, though, the process was reversed. Getting the app to debug on actual Android hardware was a simple matter of checking a few boxes on our phones. Getting it to run on iOS hardware, however, required many hours to figure out the keys and permission codes needed to authenticate our hardware for testing and debugging, due to the restrictions placed on the platform by Apple. (It also had the unfortunate side effect of wiping out George's progress in Cut the Rope.) As a result, we definitely recommend having dedicated hardware for testing and debugging with iOS, and setting it up at the beginning of the project.

Titanium itself was the right decision for this app, but was not without its own frustrations. Titanium is still very clearly a maturing product, and we ran into a number of bugs and design limitations that impacted each OS differently. The Titanium development team did their best to help out, even prioritizing a few bugs for us during development, but we still had to hack around various bugs and limitations in the API in order to ship. Titanium also lacked any form of good debugger, which proved to be a major drawback that slowed us down considerably, especially given how free-form Javascript can be at times. Ironically, late in our development cycle Appcelerator announced that they had purchased Aptana, an Eclipse-based Javascript IDE, for precisely that reason. While it didn't help us on this project, it will hopefully improve the Titanium development environment going forward.

At the same time, however, even just in the past four months the HTML5-based frameworks have improved and older, limited versions of both OSes have dropped off the market. The mobile market is still changing very rapidly, and by the time of our next mobile app an HTML5 framework may offer everything Titanium does, or at least enough of it for our needs, as well as being a development environment we're more used to. Depending on the client, we'll be evaluating both Titanium and HTML5-packaged apps again for our next mobile project. We might even consider native apps, but only if the client really does need only a single platform.

For now, the source code for the DrupalCon Chicago mobile app is publicly available under the GNU General Public License version 3. (Titanium is Apache 2 licensed and the Drupal DB port is GPLv2+ licensed, which means the app has to be GPLv3.) Hopefully it will prove useful on your next mobile project, or Palantir is available for further customizations and consultation. Let us know if you're interested.

We'll see everyone at DrupalCon London!

Comments

Interesting read.

Been playing with titanium lastweeks myself.
Since we're about to start a titanium project with drupal backend, we'll defenitly look into the sourcecode too.

Thanks for sharing!

Thanks for this very useful write-up. The App was very useful at Drupalcon, and your insights are bound to help the Drupal community move forward in bridging the gap between mobile apps and Drupal sites.

Hi,
It is awesome to know about a successful Drupal project on mobile having hooks in Drupal. We have experimented with a jquery mobile website but had to keep it outside Drupal. Just wondering if your team evaluated PhoneGap? If yes, then were there any specific reasons to go with Titanium?
I am sure not only drupal orgs but most orgs have the question of which one to choose and we were looking to go with PhoneGap.
http://stackoverflow.com/questions/1482586/comparison-between-corona-pho...

Also how would you evaluate this module?
http://drupal.org/project/jquerymobile_ui

Would it be better (quicker?) to have a mobile website (webapp) rather than an app? Good work , Keep it up.

We did look at PhoneGap as well, and our decision to go with Titanium was based in a large part on the market as it existed at the time.

As the SO thread you link to notes, PhoneGap is basically "take a web app and put it in the app store", plus making certain device APIs (camera, etc.) work since the web hasn't figured out the security model for them yet. You're fundamentally building a web app that runs in the same web browser as a web site. That means the app *looks* like a web site. More importantly, it also means your available functionality is limited by the browser that is already on the device your users are using.

As of a year ago when we started designing the DrupalCon Chicago app, there were still a fair number of older Android devices on the market that didn't support any of the HTML5-related local storage APIs. In fact, local storage is still kinda hit-or-miss for the web in general because there's 3 different mechanisms out there and none of them is universally supported (WebSQL, localStorage, and something new that Firefox is cooking up; not sure on the details off the top of my head). For Chicago, we knew that we couldn't rely on the WiFi to always be 100% solid because it never is when you pack 3000 people into one keynote room, each of them with 2-3 wireless devices. :-) That meant we absolutely had to have solid offline storage and couldn't rely on a network being available.

Titanium, by contrast, is essentially a VM. It's like writing Java back in the late 90s where you had a JVM and common code base that got mutated to each platform in bytecode, except you're using Javascript. (Folks at Appcelerator have told me that is not actually what happens under the hood; I'm not sure of the technical details, but that's what it feels like as a developer.) That meant we could rely on the Titanium SQL implementation being there on any device we chose to support. (In practice we found that there were still inconsistencies and bugs to work around but we could do that within our app with a little wrapping code.) Thus the mobile app worked perfectly fine even if someone had no data connection for the entire conference. Additionally, all of the UI controls are direct native calls so the app "looks native" rather than looking like "a web site that doesn't need to hit the network."

Since then, of course, the market has shifted. Android devices pre-2.1 and iOS pre-iOS4 are extremely hard to come by, and what people actually have in-hand have fairly good local storage support. That means today, PhoneGap probably would be a much more viable platform for what we were trying to do. If we were writing the app from scratch today it would be a serious contender; the major trade-off there would be the familiarity of HTML/CSS for UI design vs. the native look-and-feel of Titanium. I'm not sure which way we'd want to go there.

I haven't worked with jQuery Mobile, so can't really speak to it. We might actually look at Sencha, which is a more "app-y" framework for using HTML/CSS/JS for something that's totally not a web site, conceptually.

At the speed the market is moving, what makes a good trade-off today may well not be the right trade-off in 6 months. Every project will need to be evaluated individually against its business needs, the skillset of the development team, and the status of the tools and market at that specific point in time.