Building a Mobile App using Kasabi

Posted on 01/11/2012 by

2


FoundSound running in the iOS simulator

In a departure from our normal working day, we decided to see just how easy it would be to build an iPhone app that could feed data into a Kasabi dataset using Kasabi’s APIs.

We threw some ideas around and decided to build an app that could be used to record a series of sounds and order them for playback.  The simple concept of playing an ordered list of sounds, when combined with the GPS location at which the sound was recorded, means we can then build a guided tour of some place. One use case was to capture the sound of all the buskers in Birmingham, UK, so that you could see the quality of musicianship that we have to put up with. Some of them are pretty bad.

We came up with a relatively simple application design that uses the SoundCoud API to handle the upload and storage of the audio data, while we keep track of the location and playlist data in a Kasabi dataset.

We gave ourselves a week to build this, and we definitely learnt a lot on the way.  None of us has ever built a mobile app before, so we wanted to try out the PhoneGap mobile framework because using HTML and Javascript was something we were familiar with. Using a hybrid mobile development approach (HTML5 + Javascript + native wrapper for access to the phone’s capabilities) gives us good options for porting to other platforms, though we didn’t try other platforms in this exercise.

I’m not going to delve into the code at this point (which was pretty ugly by the end of the week) or how we solved different issues in detail, but instead I’m going to briefly describe how our time was spent building the app.

  • Day 1: Generating an idea and fleshing out how we thought it might work using a whiteboard and then paring the idea down to something that might be achievable. This included working out what sort of data we wanted to capture, and a rough data model.
  • Day 2: Starting to use PhoneGap for the iOS platform and working out what we needed to do to get a working app compiled in Xcode. Because we were using a Javascript + HTML5 development framework, we started using Sencha Touch to flesh out our basic user interface. We pondered on a name for our app.
  • Day 3: Decided to stop using Sencha Touch in favour of jQuery Mobile.  While Sencha Touch looks very good, and was the sort of styling we were after for our app, it’s a pain having to write every UI view as JSON objects, and proved too slow to get a basic UI in place in time.  jQuery Mobile works much like its browser based cousin, and because the bulk of the pages or UI views can be fleshed out as HTML, it made it an awful lot quicker to get a working clickable prototype running. We continued thinking of a name for the app.
  • Day 4: Meanwhile we still had to get SoundCloud oAuth2 integrated into the app, this was a bit of a learning curve, despite pretty thorough documentation. We added some PhoneGap plugins to manage keychain access and child browsers to make the oAuth process friendlier. Somewhere along the line our Xcode project got corrupted and so we had to rebuild that.
  • Day 5: Spent a while discovering that jQuery Mobile’s CSS rules are somewhat clunky to override, but were able to start moving away from the default jQuery look and feel. By the afternoon of day five, we were ready to post some data to Kasabi, so we added a jQuery.ajax() request to post the data to the kasabi update API.  Posting to our Kasabi dataset only took about half an our to implement.

The code isn’t ready for showing yet, and there will be some changes to how we manage our Kasabi API keys. The main thing I want you to notice in the above description of our week, is the bit where we implemented storage of our data in Kasabi using the update API. Our APIs are easy to work with if you know how to build a straight forward HTTP request in your chosen development language, and take a lot less time to implement than some of the other features we worked on.

The other thing I want you to notice is that at no time did we have to buy any storage or server infrastructure to host our data with. Kasabi does all of that for us, with no capital outlay.

What we haven’t done yet is built up enough real data to start on the search and playlist views, but those will be coming, and will use Kasabi’s search, SPARQL stored procedure and lookup APIs.

If you want to know more about how Kasabi can be used to get a mobile application running against custom data, get in touch with me, Tim Hodson (Developer Advocate).

Posted in: Uncategorized