DrupalCon in your hand: the DC Sydney mobile app


DrupalCon is the biggest conference held in the Drupal community. Since 2005, it has run in ten countries across the world, growing from under 50 people at the first DrupalCon in Antwerp all the way up to 2012’s conventions, pulling in over 3000 people in Denver alone.

In 2013, for the first time, DrupalCon is being held in the southern hemisphere, in CrossFunctional’s hometown of Sydney, Australia.

Apart from being the platinum sponsor, CrossFunctional has developed a mobile application that runs on iOS and Android for DrupalCon Sydney. In this post, we’d like to discuss its functionality, the methods we used to create it, and the challenges that we faced developing this
hybrid app.

To download the apps and try them out, grab them from the iTunes Store and Google Play store using the links below.

Download on the App Store for iPhone, iPad and iPod Touch    Android app on Google Play

We've spotted a few bugs in the first release of the app, so we're doing our best to rectify them and should have a new version out well before DrupalCon begins. There's also a Windows Phone version in the works, so watch this space.


Before we go on any further, here’s a brief list of the app’s features.

  • Offline access to the entire program guide including sessions, BOFs, and keynote
  • Get live updates while on Wifi or 3G
  • Allows users to bookmark sessions and build your own personal schedule
  • Watch the DrupalCon Twitter feed
  • Authenticate against your own Twitter handle, and submit your own tweets with the #DrupalCon hash tag.
  • Access floor plans of the official venue
  • The iOS version works on iPhone, iPad and iPod Touch.
  • The Android version works on over 2000 devices that support the Google Play store.

Now, here are some pretty pictures:

Session category list   Details of a particular session   A list of tweets

The app layout was done in-house by CrossFunctional, and we used the logo, assets & display elements by Lee Olsen from ShiftRefresh.

How it was built

The DrupalCon app is very particular kind of app, known as a hybrid app. Hybrid apps are originally built using web technologies such as HTML5, JavaScript and CSS.

To make them able to access the advanced functionality that particular platforms offer, and to make them releasable in various app stores, we used a framework, in this case PhoneGap, to convert the app into to its native form.
“Native form” means that the app will converted into the language that the its Operating System is written in. For Android it will be Dalvik, and on iOS it will be Objective C.

Specifically, what PhoneGap does is that it runs the HTML5/CSS/JS segment inside a WebView, which is like running a web browser within the native app. From there, the JavaScript code running in the WebView can make calls outside the WebView to the device’s native functionality or other websites.

PhoneGap is a relatively popular framework for hybrid apps, and has quite a bit of developer support behind it.

How It Works

Technologies used

To obtain data including session listings and info pages, the app pulls down JSON from a source and stores it locally, using the HTML5 Offline Storage APIs. This ensures that if people lose connectivity (as is inevitable at conventions where there are a lot of phones in close proximity) that they would be able to have at least the schedule and conference info on hand.

On the server-end, we used a script to connect to the DrupalCon Sydney website and output the results as static JSON, which we then cache. Every time the app loads, it polls the site to look for updates; if they’re available, it downloads them and uses them. We used the jQuery JSON plugin to parse and render JSON.

To render out the results in a consistent form, we used the Knockout templating engine to take the raw data and apply it to HTML templates. The engine is lightweight and flexible, and even allows us to update the templates as new data comes in, which was indispensible in particular when dealing with the Twitter feed.

Other things we used libraries for:

  • iScroll to display venue maps
  • Moment for formatting dates nicely
  • noClickDelay for removing the built-in delay between touch and response on iOS devices


We’ll be honest with you, building a hybrid app isn’t an easy thing. We hit a number of issues as we worked, which informed the way we worked and will work with mobile apps in future.

Cross-Platform Development

One of the touted benefits of building a hybrid app is the “write once run everywhere” ideal, which supposedly has the ability for you to spend more development time on your core application without having to worry about the platform. This works a lot of the time, but we did end up spending a fair amount of time on platform specific tweaks.

For one thing, if you want to open a URL in an external browser, you can’t even do it the same way on iOS and Android. It’s actually pretty complicated to get it working the same way.
For iOS, you either need a link with the target attribute set to _blank, or you need to have a particular parameter in your Cordova plist switched on to enable whitelisting for links opening within the main WebView, and the link needs to not be on a particular whitelist.
For Android, you need to run the navigator.app.loadUri JavaScript function, which isn’t even available on iOS.

Another issue we faced in terms of cross-compatibility was getting the Twitter plugin working. The iOS and Android plugins offer a different set of functions, and they access the Twitter plugins using different device names.
For iOS, you’re calling the com.phonegap.twitter plugin, and you need to check isTwitterAvailable and isTwitterSetup to determine whether the OS supports it and if the user has an account available. Once that’s done, you can call composeTweet as normal to post your tweet using iOS’ Twitter functionality.
For Android, you only need to call the Twitter plugin’s isTwitterAvailable function, but that depends on a compatible Twitter client being installed on your device. Once that’s been identified, composeTweet calls on that app to post the tweet.

iOS Development

Developing for iOS requires that you have a Mac and Xcode, there’s no way around it. You don’t strictly need a Developer license unless you want to test on your devices, but you will want to do this.

Logs for debugging is kind of problematic, because console.log does not necessarily expose to Xcode nicely, and popping alert calls in all over the place gets problematic quick. It might be worth your while to try out something like http://jsconsole.com/ to do your logging.

If you’re not developing on your devices most of the time, the iOS emulator is generally excellent. It’s fast, covers whatever devices you want, and while I haven’t tested multi touch functionality with it, it translates mouse clicks to single touches with ease.

Android Development

I’ll be straight with you: in my opinion, the Android emulator is horrible, and probably shouldn’t have ever been released. It is agonisingly slow, doesn’t even load your APK most of the time, and is generally very buggy. Don’t waste your time with it, get an Android device or three to test on!

It’s not really that difficult to set up a workflow to get your APKs onto the phone with Eclipse and USB transfer, or to set up your device as a debugging device. It’s much easier to do the latter if you have a device that has some friendly details on how to do what you like.
The Kindle Fire by Amazon is actually pretty nice for development, and it has some great developer docs that show you how to get it going quickly and easily on whatever machine you’re developing on. In comparison, the Samsung Galaxy 5 I also used for testing required that I installed Kies and jump through a whole bunch of hoops if I wanted to use it to debug. I opted to stick with the Kindle; dealing with Kies wasn’t worth the effort.

One related issue I faced was not actually having any devices running Ice Cream Sandwich or Jellybean to test on. Since I was targeting the APIs used by Froyo and above, I feel somewhat reassured that they work on the newer devices, but I couldn’t really be sure because of the inadequacy of the emulators to be able to get anything done.
I’d certainly feel a lot more at ease if I had a Nexus or something to test on. Note to self...

Other Experiences

Once your app is developed, tested and cleaned up for release, it’s time to get it on the app stores! There isn’t really an easy way to do this, so regardless of what stores you’re deploying to, it’s best to follow a few major points.

  • Get paid up
    All the major mobile Developer Programs require some outlay of cash for a subscription, like it or not. For an organisation these costs are like a drop in a bucket, and for some solo devs it might be worth your while doing so.
    For a year’s subscription (this is at the time when this blog was written):
  • Read the documentation
    Each app store has a different set of requirements. For instance, the iOS app store requires a whole stack of assets and metadata at app creation time, but lets you upload your app package later on. While the Google Play store doesn’t require everything at once, it insists on using a slightly different set of requirements which might need you to plan your assets in parrallel. 
    It’s a great idea to read through the documentation carefully so you’ve got a good idea of what’s required in the app submission process.
  • Make a checklist
    With so much stuff to keep track of, it’s a good idea to make a checklist of everything you need at an early stage. This will let you keep track of all the little steps involved in publishing your app; moreover, once you’ve got it down pat, you can start finding ways to streamline the process and get your apps out the door quicker.
  • Gather your assets
    Each app store has a list of things they require to sell your app. This includes some obvious things like a title, description, some screenshots and an icon. However, it might also include things like a list of search keywords, screenshots for differently-sized devices, a page containing your app’s privacy policy and a promo page for your app. It’s a good idea to start collating these before you decide to try and submit your app for the first time, because some stores such as the iOS store require that you have everything in order before you submit.
  • Sign your apps
    Don’t forget to sign your app packages! iOS will require that you download certificates will be installed on your machine; Google Play will let you set up certificates yourself, but will insist you use theirs if you use particular APIs.
  • Pay attention to the validators
    Apple’s app store in particular has a well-acknowledged but opaque validation workflow. It’s best to respond to all requirements before you submit your app, and the iOS app validator in Xcode will help with this. If you’re able to rectify issues quick, such as uploading new screenshots or updating information, you should be able to get past any validation roadblocks quickly.


There’s a lot of work involved in creating a hybrid app for most any purpose, but I’ve felt that all the work that’s been put into the DrupalCon Sydney app has been worthwhile. It’s taught me a lot about development on mobile devices in general, and has helped me at least get started; with any luck it might lead to bigger, better things.

To those of you who will be at DrupalCon Sydney: hope you find the app useful, and we’re looking forward to seeing you there.


I wrote a similar app for DrupalCon Munich using the Sencha Touch framework.  Unfortunately, I had no cooperation from the event organizers, and hence could not get all the session data in advance nor any kind of live feed.  I didn't feel like typing in the data for hundreds of items, and without a way to update them for accuracy as the event progressed, my app became an academic exercise.  It worked fine, but was effectively useless.  
I'm glad someone else has seen the light.  What could possibly be more convenient at such a large convention than to have the schedule and other information in your pocket?  
Congratulations on a job well done.  I think convention goers will find it to be extremely helpful.

Can I get sample source code of this? I'm learning how to develop mobile app with Druapl's content.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

glqxz9283 sfy39587p10 mnesdcuix7