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
To download the apps and try them out, grab them from the iTunes Store and Google Play store using the links below.
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:
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
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.
PhoneGap is a relatively popular framework for hybrid apps, and has quite a bit of developer support behind it.
How It Works
- Markup - HTML and CSS
- Offline storage - HTML5 offline storage
- Data interchange format - JSON
- Interface - app-UI
- Templates - Knockout
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.
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.
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.
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.
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...
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
- 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.