Couchbase Live London 2014 stackedI was fortunate enough to attend this years Couchbase Live [London] event. Having experience with MongoDB in production with one of our clients I was keen to see what Couchbase has to offer.

Viber were on scene to talk about their decision to migrate from a MongoDB backend to Couchbase. They started off using MongoDB for persistence, with Redis in front of the Mongo instances for caching, they found that the setup just wasn’t scaling out as they needed so opted for Couchbase and were able to reduce their server count by three fold. Switching to Couchbase simplified their persistence architecture and enabled them to have several clusters and a dedicated backup cluster using XDCR (cross data centre replication).

The first session I went to was “Anatomy of a Couchbase app”, where J Chris Anderson (@jchris) and Matt Revell (@matthewrevell) gave a demonstration of a Node.js and Couchbase backed application that enables users to post video clips onto a web page; like a chat room for pre-recorded videos. As a developer, this session was my favourite, after a quick demo of the app they dived straight into the code and showed you how to use the APIs (from a Node.js perspective, but other languages would have similar features). They covered auto-expiring documents, and binary storage, which were two things I wanted to see how Couch handled, as I already knew MongoDB had good support for these. If you have time, look at the application, it’s on their github

Another session that I found incredibly useful, was “Document Modelling” by Jasdeep Jaitla (@scalabl3). Whilst I already have experience working with MongoDB in production, I have a good understanding of how a document should be structured, but I was a little unsure of how this is implemented in Couchbase. For a start, MongoDB uses collections within databases, whereas Couchbase uses buckets, so there is one less layer of abstraction, meaning buckets can store different types of documents. Also, Couchbase is a key-value document store, so your keys could be a string such as “user:1″ or even just “1”, and the value itself would be the json document (or binary data).

Couchbase also has the concept of document meta-data, for every document stored, it will have a corresponding meta-data document that stores things such as the Id, an expiration (for TTL purposes), document type. The document itself can be up to 20mb, as opposed to 16mb in MongoDB.

Jasdeep then explained various patterns that can be used for storing data, such as a lookup pattern, and counter pattern. This was very useful.

The mobile sessions were not quite as good, I was expecting more of a workshop style whereby we could see some code and get advise on how to implement CBLite, however there were some very good demos of a todo-list and syncing data between various devices (android smartwatch included!). If you’re interested, have a look at the grocery-sync app on github, it is very similar.

The last session worth noting, was from David Haikney; “Visualising a Couchbase server in flight”. David discussed (and demonstrated, perfectly) replication, fail overs, scaling and XDCR. He had a cluster of servers, and was able to remove and add new nodes and demonstrate how the rest of the cluster reacts to such scenarios. You can get a lot of information from the statistics that are built into the admin console, and the top tip I picked up was to ensure the active docs resident is close to 100%, as that shows documents are being served from memory instead of disk.

Some other advice was to take advantage of XDCR, such as creating a backup cluster, or live-hot standby setups, or even using XDCR to replicate to a test environment so that you always have representative live data.

There was a hackathon in the evening, I stayed for this but didn’t participate as I was too keen to setup bucket shadowing on a demo app I was working on. The beta3 release of the sync gateway introduced this feature whereby you can configure your sync gateway bucket to automatically sync with a standard bucket, this is fantastic for exposing your applications data to a mobile tier (you can restrict this of course, using channels). If you want to read more, have a look here.

A great day, I learned a lot, well worth the trip. I even bagged a free Apple TV for being one of the first through registration…



Please Rate and Like this blog. Share it using the social icons below or via the short URL

Our readers want to know what YOU think so please take a moment to Comment.

Last week I was fortunate enough to attend my 4th annual DroidCon UK. DroidCon is a 2 day conference held at the Business Design Centre in Islington. London and encourages Android developers and enthusiasts to come together and share their ideas, apps, and advice.

As with previous years, the first day is a bar camp (45 minute talks that are decided on the day, based on who is there and who wants to present something). The second day is more structured with a pre defined schedule of talks. There are also vendor booths around the main hall promoting their products and services.

The purpose of this post is for me to summarise the event and mention some of the key things I took away from it.

Dependency Injection on android
The first talk discussed dependency injection and how it can be achieved on android via libraries such as RoboGuice and Dagger.  A quick show of hands made it clear that very few people in the room are actually following DI. Coming from a predominantly Java/Spring background, I understand the benefits of using DI (giving objects exactly what they need, loose coupling and easier testing), but there is a certain stigma that DI holds when mentioned alongside android. RoboGuice is often assumed to be the “go-to” DI framework, however there is a new kid on the block, dagger, from square.

Without a doubt, this was my favourite session from the conference, I was impressed with the service they offer, and its free! For those of you that have at some point developed an android app, chances are you’ve emailed the APK around to a few friends and asked them to check it out. They may have encountered some errors, but all you’ll likely hear is “it crashed when I clicked the blue button”, which isn’t entirely helpful.

Fortunately, the guys over at TestFairy have developed a service whereby you can upload your APK to your online account, and distribute it to your friends. When your friends install and open the app, their interactions are recorded, so if there is an error you can see a video clip of what they pressed in order to get the error. Logs are included, along with various other useful information such as battery, cpu, memory usage. Finally, you spot that bug that only occurs if an incoming call occurs whilst on your app! Please, please go check them out.

OCR on android
Next up was another bar camp discussion around OCR on android and how it can be achieved by using OpenCV. I was quite interested in this talk as I have done some work with OCR on android/iOS for Aviva. The discussion covered the basics of using the OpenCV library, however the emphasis was mostly on how non-trivial OCR is. I can certainly vouch for that, in order to get results that are even remotely close I needed to use blacklists and whitelists for characters, and pre-process the image. If you’re interested in OCR on android I’d highly recommend having a look at the tess-two project on github, which is a fantastic java wrapper around tesseract tools.

I haven’t delved too deeply into SQLite storage on android, but from what I did experiment with it wasn’t the easiest of APIs to work with. Fortunately there is a library called Cupboard that makes this easier with its fluent API. Hugo Visser, the creator of Cupboard gave a brilliant talk on how to get started using it.

Instant backends with Windows Azure
Microsoft, at an android conference, not what you’d typically expect, however they did provide a great session on how to get started building mobile backends on the Azure platform. Microsoft provide an intuitive interface so you can quite quickly create and deploy a backend with social sign in via the usual providers (Google, Facebook). You’re also able to download client libraries so that you can quickly and easily exchange data between your backend and the mobile client. Whilst this looks like a promising offer enabling you to get moving fast, I’m quite sceptical about whether or not ease/speed is still a benefit once your backend becomes more complex.

There is an excellent tutorial here

Mobile backend starter, from Google
Google is also on the BaaS scene, offering the mobile backend as a starter. This is based on the existing Google cloud platform services like app engine and cloud store. Similar to the Azure offering, you’re able to deploy a sample backend in a few clicks and are given client libraries to make the communication as easy as using a Java API.

A colleague of mine, Charlie Simms also attended the event, here is his take on it

A variety of SDKs were promoted at this years event, such as :

So what did it for me:

The event had 86 line ups so there was plenty to choice from, but having done my MSc at Surrey and been on a Satellite Communications Workshop ( ) I was very interest and puzzled in the Keynote on Friday morning “Smart-Phones in Space” why would you want to put a mobile phone in space. Dr Chris Bridges lead a small team at Surrey University Space Centre ( ) to launch a Nexus 1 into low Earth orbit. This talk provided the journey of the first of many ‘phone-sat’ projects and how hardware and software challenges were overcome to achieve this scientific feat in teaching and research. A brilliant talk both interesting and demonstrating what advanced technology is packed into a smart phone.

The second thing that did it for me was the talk by Benjamin Cabé  “Leveraging Android for the Internet of Things with Eclipse M2M”. Benjamin is an Open-Source M2M evangelist and chair of the Eclipse M2M project ( This talk briefly introduced the Eclipse M2M projects with cool end-to-end examples, combining the use of Android API for doing fleet tracking, remote monitoring, and home automation. Also discussed importantly is the challenge of operating large fleets of M2M devices, with the need for cloud-based scalable infrastructures. With the vast amounts of data being collected from possibly billions of sources there will be an ever greater need for cloud base services and the support for big data. The internet of things still in its infancy but it won’t be long before it starts to impact all our lives in the same way as mobile technology is doing today. Certainly a space to be watched closely.

The weird and wonderful

If you’ve made it this far, then lets end the post on some of the weird and wonderful ways that android is being used.

This year we had the worlds (probably) only android powered hydroponics system for growing plants indoors.


Android powered hydroponics system from Seraku

There was also an android enabled car, an android powered mirror (which you can operate with your best Tom Cruise “Minority Report” impression), and a guy controlling an android powered robot via his android powered smartwatch

Lego Mindstorms robot controlled via AndroidScript / Smartwatch

Lego Mindstorms robot controlled via AndroidScript / Smartwatch

I feel that every year droidcon has a bit of a theme to it, well perhaps not a theme as such, but there will be one or two topics that are in the limelight of the conference, last year felt like the focus was on NFC, this year there was quite a focus on the backends and security, which may pinpoint androids evolution into the B2E space. With presence from Motorola Rhomobile promoting their enterprise platform, droidcon isn’t just attracting indie developers and B2C solutions.

Please share this blog using the social buttons below or via this short URL

Please Rate and Like this blog.  Our readers want to know what YOU think, so please take a moment to leave a Comment.

Old record player

Photo: Old record player by Grafphotogpaher (c) Dreamstime Stock Free Images

Those of you accustomed to developing android application will be familiar with the mechanism used for building android apps, such as having the IDE do the work for you, which is somewhat limited, or breaking out and writing ant scripts to orchestrate a build. Some of the adventurous amongst you may be using the maven-android-plugin.

It appears that the Google Android build tools team has come to terms with the fact that ant probably isn’t the best option these days, and are moving towards replacing ant with gradle in the SDK in the future.

Last night I was fortunate enough to attend a event with the London Android Group (@londroid) at the SkillsMatter (@skillsmatter) HQ, where Hans Dockter (@hans_d), the CEO of gradleware gave a presentation on what gradle is, and how it can be used for building android projects, enabling developers to manage their builds with groovy based scripts rather than XML.

What is a build framework anyway?

As Hans put it so well, in short, a build framework will “compile stuff, copy things around, and drop out an archive“.

Whats so limiting with the current options?

Ant can be considered imperative, simply meaning that you have to spoon feed it with instructions via tasks; compile these files that reside here, copy them to this directory, jar it up etc, its not really capable of figuring things out for itself.

Maven on the other hand is considered declarative, meaning that you can focus more on the outputs of a task, such as “I want a web application”, providing you have your source in the right place, maven is smart enough to figure out where to find it, how to compile it, and what the output for a web application should look like. Essentially you tell maven what the inputs are, and what you expect to get out of it, and maven figures out the bit inbetween, thus avoiding the need for scripting tasks as you would have to if using ant.

Sounds great, so what does gradle bring to the android party?

Free beer! If only…but we get the next best thing.

Gradle attempts to take the best parts of ant and maven, by using it for building your android projects you can benefit from:

  • Very light and easy to manage build files, no trawling through humungous XML files. (gradle vs maven).
  • Gradle follows convention over configuration like maven. It knows where your source is for a java project (unless you decide to override it), you can read more about convention over configuration here.
  • Flexible dependency management, integrate with existing maven/ivy repositories. Different versions of dependencies for different build tasks? No problem.
  • It gives you the freedom and flexibility to define your own custom behaviour without needing to write plugins as you would if using maven. Groovy is your friend here.
  • Support for multiple projects. You don’t need to have separate projects for production code and integration tests, you can have keep them within the same project and define different source sets. This greatly reduces parent/child projects that can be a chore to maintain.
  • Don’t have gradle installed? Can’t install gradle easily? No worries, there is gradle wrapper for that. This is particularly useful on CloudBees Jenkins environments where you don’t have access to install gradle directly.
  • You have a free and paid for version of the app, with some common shared library between them? Gradle handles this perfectly via product flavours
  • In addition to free and paid for flavours, you also have builds for different architectures such as ARM and x86? Flavour groups will help you there.
  • You’re not tied to an IDE, the build scripts should be IDE independent so your team can choose their own flavour of IDE, or build from the command line as you would on a jenkins environment.
  • Don’t want to use Eclipse, prefer IntelliJ instead? No worries, apply the idea plugin and run gradle cleanIdea idea. Boom, idea project is setup and ready to go, no messing around with project settings.
  • Easily run instrumentation tests on multiple virtual devices, no need for manual testing each time you make a change.

Getting started?

  1. Watch the presentation
  2. Read through the android build tools page, plenty of information here on how to use the android gradle plugin
  3. Have a read of the gradle documentation, its very well documented.
  4. Checkout the samples on github
  5. Have a browse of the groovy documentation so you can understand the basic syntax of the language.
  6. code, code, code!

Make sure you join the London Android group on and look out for future events like this, they’re free and well worth the train ticket. For those in the south east, be sure to checkout SyncIpswich and SyncNorwich for free technology meetups.

Having recently spent time working on the IBM Worklight platform, I thought it would only be fair if I documented some of my findings. No disrespect to the IBM’ers, but its reasonably fair to say that documentation is a little sparse in places, so lets give a little back to the community by discussing some of the hurdles. Lets not dwell on what Worklight is, Andy has already covered this well in a previous post; but lets just dive right into some of the technical aspects.

General Thoughts

Development on the whole is a relatively straightforward process, even for someone like myself that often steers well clear of anything that involves web presentation technologies (it reminds me of dark nights at the university labs spending hours trying to get a button to align correctly, the night before coursework submission *shudder*).

The Worklight eclipse plugin provides a good drag & drop GUI builder, but with support only for dojo. I opted to drop dojo and go for jQuery. jQuery is very well documented, and is easy to get help should you require it. One of the main things I like about jQuery is its showcase and examples, they are documented very well and the learning curve is generally quite small, but also the themeroller, it becomes incredibly easy to customise the default colour scheme and drop the generated CSS into your app. It always amazes me how excited the marketing guys will get if you can add in the corporate colour scheme to your app (thanks Joseph!).

Continuous Integration

We’re big fans of CI here, so I was quite keen to understand how easy it would be to have our Worklight apps built from the command line, and ultimately on a Jenkins CI box. The chaps over at IBM have done a fantastic job of exposing an array of Ant tasks that help with building and deploying apps, you’ll almost certainly want to read through module 42 on the getting started page that covers these tasks:

  • adapter-builder – Use this task to build your adapter and create the .adapter file
  • adapter-deployer – Use this to deploy a .adapter file to a Worklight server (very  useful for deploying to a remote AWS instance)
  • war-builder – Use this to build the server .war file that you will deploy to the application server (some manual tweaks are required)
  • app-builder – Use this to build the .wlapp files that you will deploy into your Worklight container
  • app-deployer – Use this to deploy your .wlapp files onto a Worklight server (useful again for remote deployments)

Lets have a closer look at each of those targets, and how we’re using them here at Smart421:

Getting the party started, with init

Firstly, grab the worklight ant jar (you’ll need to have purchased the WL Enterprise edition for this) and add it into your ant context like so :

<target name="init">
 <echo message="Loading ANT Tool"/>
 <taskdef resource="com/worklight/ant/">
 <pathelement location="./build-config/worklight-ant.jar"/>
 <property environment="env"/>

Now you’re free to use the ant tasks anywhere in your build script.

Building & Deploying WL Adapters

You need to build each adapter individually, and then deploy each one. You can create the following ant targets to do that for you:

<target name="buildAdapters" depends="init">
 <echo message="Building all adapters"/>
 <!-- Build your other adapters here, same as above-->

<target name="deployAdapters" depends="init">
 <property name="WLSERVERHOST" value="http://my_aws_ip_here:8080/SmartConf"/>
 <echo message="Deploying all adapters"/>
 <!-- Deploy your other adapters here, same as above-->

Building the Server WAR

You can build the server war file using the war-builder task, as shown below. It is important to note however, that I needed to do some tweaking to the war file to avoid any post-installation configuration tasks. According to the Worklight forums, there doesn’t appear to be a way to include files in the WEB-INF when the war is created, which means that once you’ve expanded the war on the application server you’d need to manually replace the default web.xml and context.xml files (to set your datasources), this can be quite frustrating, so in true Blue Peter fashion, I’m updating the war file with files I created earlier.

<target name="warBuilder" depends="init">
 <echo message="Building the war file"/>

<target name="updateWar">
 <echo message="Updating the war file"/>
 <war destfile="./bin/SmartConf.war" update="true" webxml="./build-config/web.xml">
 <metainf dir="./build-config" includes="context.xml"/>

Building & Deploying the WL Apps

You’ll also want to automate the building and deploying of the wlapp files, you can do this with the following :

<target name="buildApps">
 <echo message="Building all WL Apps"/>

<target name="deployApps">
 <property name="WLSERVERHOST" value="http://my_aws_ip_here:8080/SmartConf"/>
 <echo message="Deploying all WL Apps"/>

Building the Native Application Distributable Binaries You’ve survived this far, and I’m thankful to you for that, however we’re not quite finished yet. Worklight will generate the native projects for you, but its your own responsibility to take those project directories and build the Android APK, or the iOS IPA etc. IBM will draw the line at this point, so you need to build them yourself, you can do this for all of the environments quite easily using additional ant tasks, android is the easiest :

<target name="client-android" depends="buildAndroid">
 <!-- Run the android native build, in its own directory -->
 <ant antfile="./apps/SmartConf/android/native/build.xml" target="release" useNativeBasedir="true"/>
 <!-- Copy up the apk into the bin area, for consistency -->
 <copy file="./apps/SmartConf/android/native/bin/SmartConf-release-unsigned.apk" tofile="./bin/SmartConfSmartConfAndroid.apk" overwrite="true"/>

Building Blackberry and iOS apps from the command line is slightly more involved, and I feel they warrant their own blog post on that, alternatively, get in touch and we’d be glad to offer some assistance. Bear in mind you will need an Apple MAC to build iOS, for which we’ve installed a shared box in our build environment.

Other Gotchas

As with taking on board any emerging technology, there will always be plenty of head-scratching moments where the documentation is thin, and Uncle Google doesn’t provide much help, fortunately for you, we’re a nice bunch of guys here at Smart421 so we’ll share some of the things that had us pondering over a coffee:

  • The trailing “/” in the Worklight server host URL is required, don’t ask why, it just is.
  • The versioning conventions for Worklight are a little strange5.0.0.270 = v5.0 GA, but the developer edition is =
  • If you have an existing WL server installation, don’t upgrade it to, it fails to upgrade all components and leaves you with some obscure error messages that are hard to trace. The best plan of action is to uninstall, install again, but make sure you check for updates at time of installing, via the wizard
  • App crashes with Unreachable host? When you build and deploy the app to your device, it has the WL server IP hardcoded into it. The next day when you arrive at the office and hop onto the Wifi, DHCP gives you a different IP address…It’s a classic schoolboy error, but catches us out from time to time. A simple solution if you don’t have a spare box lying around is to install the Worklight server on AWS and deploy to the cloud, bearing in mind that it needs to be open to your mobile devices over the Internet in a real-life installation anyway.
  • Results is undefined on adapter call. A subtle difference here, HTTP adapters use invocationResult.results, whereas SQL adapters use invocationResults.result. That last character makes all the difference.
  • Response cannot be parsed, please contact support; this is an annoying error that you often see in the developer preview, just make sure you set the body onload to WL.Client.init() as mentioned here.
  • Unable to use geolocation services on android? You’re probably seeing Caught security exception registering for location updates from the system, this should only happen in DumpRenderTree. Make sure you have the geolocations permission in your android manifest as detailed here.


On the whole, I was very impressed with Worklight, they are offering a lot of functionality over and above the standard Cordova project. Some of the errors I’ve encountered have been a little frustrating, as often my only source of help was the forums, but I can accept that it is a product in its early stages of adoption, and will probably go very far. I’m looking forward to working with it in the future.

If you’d like to have a look at some of the apps we’re creating, or generally just want a chat about Worklight and some of its capabilities, or Mobility in general, we’d love to hear from you.

It’s just passed that time of year again….not Christmas…not thanksgiving…but DroidCon! Being one of many enthusiastic mobile geeks that we seem to cultivate of late, I was able to sneak off from my project work for 2 days to see what is happening in the world of android mobile development. Here are some of my highlights from the conference.

Android for a Vending Machine

Paresh Patel (@DrPareshPatel) from Vendscreen gave an inspiring talk regarding how his company are thinking outside the box, and bringing android to everyday devices that we wouldn’t typically associate with mobile computing, such as vending machines. Vending machines can no longer be dumb service machines that refuse most of the coins you have in your pocket, and when it eventually accepts it you’ll be praying the mars bar does actually drop and doesn’t get stuck half way.

One of the fundamental gaps in the vending machine model, is that once the manufacturer has shipped the product, they have no realtime visibility of the retail flow to the user, however, if the vending machine was smart enough to recognise the purchases, this data could be fed back directly to the suppliers so they can see that a given vending machine likes to sell mars bars at 3pm on a Friday afternoon.

This is where Vendscreen come into play, they have developed a device that can be installed into the machine, that uses the android operating system to enable product resale information to be gathered and fed back to the supplier, of course, being an android powered device, there are many other benefits such as cashless payments via NFC, and servicing info that can be relayed to the operating company should there be a fault with the vending machine, or alarms being set off at head office on Friday at 3:01 pm as the chocolate crisis begins.

Additionally, vending machines could then be clustered; to offer more alternative products, not to combine computing power in a Skynet attempt to bring down humanity. If you have vending machines on all 10 floors of your office block, you no longer need to have the same 40 product lines in each one, you can have a core set of 15 products, and 25 varying products, totalling over 100 various items in the building. Users can then be notified of which floors a particular packet of crisps may reside using the on screen menus.

Android for a Car

Another interesting talk came from the guys at Parrot, regarding their new range of android powered in-car systems named “Parrot Asteroid“. These devices allow users to expand their regular hands-free system to incorporate media players, GPS navigation, and a wireless hotspot. Whilst the products were marketed well, I’m not convinced they provide anything more than what you could do on a regular android powered smartphone.


This talk discussed what fragments are, and why we should be using them. In short, using fragments makes your life less painful when it comes to making your application usable on varying sized devices. One way of describing fragments are sub-activities, whereby you can have many fragments in a single activity that have simple and well defined purposes. You can then display fragments at runtime dependant on the device, so a phone may have a nested list whereas a table would have enough space on the screen to display a contents pane, and a detail view. This image from the fragments documentation sums it up reasonably well.

Have a look at the GMail app for the phone and a tablet and you’ll see a good example of this, iOS has a similar UI component called MasterDetail. One quote from the presenter was “If you’re not using fragments, you’re writing legacy code“, I must admit I disagree with this statement, since there are times where it is either overkill, or inappropriate to be using them, such as developing games which would require a fixed canvas, so as good as fragments are, they’re not the silver bullet.

Continuous Integration using Jenkins

Using Jenkins on a daily basis, I’m already aware of how awesome it is, and having several of my own android projects on the go I’m aware of how much benefit it brings to the android development life-cycle, but I wanted to hear this from other people to ensure it wasn’t just me that had a secret loving of the butler. One of the best things you can do with the android-emulator-plugin, is to define a set of emulators that you’d like to instantiate, deploy your app to, and then run your integration tests on.

Not only can you select multiple versions of the emulator, but you can also select multiple locales, device screen sizes, memory sizes, and more. This enables you to deploy your app to the most common device configuration, but also for weekly jobs you could deploy to less common devices, and varying locales to ensure your internationalization is working as intended. Combine this emulator plugin along with a little research onto the popular device combinations of your target audience, and you’re well on your way (provided you actually write the tests of course).

Following the TDD principles early can reduce the amount of time you’ll spend trawling through the logcat later on when you introduce some obscure bug that your missing regression tests could have detected:

Using the Facebook SDK

If you want publicity for your app, Facebook is a very viable option, with a user base of 1 billion active monthly users, there are potentially a lot of likes that you can earn, but not only that, downloads! Having recently developed a gamification app for one of our clients, I was well versed in the Facebook SDK for iOS and some of the pains it brings with asynchronous requests to the open graph, and authentication, however for the latest android SDK it seems a lot of these have been addressed. Session management is now handled automatically, various manual parsing of JSON is now reduced to handling Java objects, integration with the OpenGraph has been made a lot easier, so you can post detailed actions to your timeline, a lot of the UI components that you’d otherwise have to create manually are now available out of the box, such as friend and location pickers, and deep linking is provided so when users click on a link to your Facebook app, it will open the app on the device if it is available, otherwise direct them to the market to download it.

NFC With Mark Murphy

OK, so his live demo didn’t actually work, but he’s the celebrity of the android world so I’m sure we can all forgive him for that. A fantastic public speaker, Mark gave us an entertaining overview of how easy it is to get started using NFC, you can have a look at his sample on Github here. Mark discussed how you can easily read and write data to tags, however current tags are limited to around 1kb of data, so don’t expect to be seeing Kindle books delivered on the back of a postage stamp any time soon. There were a handful of other talks around the NFC technology, and the vendors had NFC tags in posters, and some were even giving out free NFC tags if you pleaded nicely.

Write less, do more

Yes, very appealing, this discussion was around some of the useful, free, open source libraries that are available to make android development easier by removing the need for developing your own boilerplate code; some interesting libraries that cropped up :

Overall another fantastic year, I’ve completed the “droidcon hat trick” now and each year I can see that more people are becoming serious about mobile development. It was clear that NFC is going to be taking off and as the technology is reasonably new, the market isn’t too saturated with ideas, thinking caps need to go on!

This video was played many times by the DroidCon organisers on the big screens, it’d only be fair to pass it on!

Watch this space, I have some thoughts around IBM Worklight, NFC, and some of the other technologies mentioned here that may be hitting your RSS readers soon…

Last year I was lucky enough to attend the DroidCon Android conference in London, impressed by what I saw, I presented my case to return again for the second year, to scout out information on Android developments.

As usual, the format of the event is a 2 day barcamp, where various representatives from all areas of the industry present a topic which they feel strongly about, ranging from anything about UI design, design patterns, right through to commercials such as marketing and business considerations when releasing an application.

The first day consisted of informal discussions on various topics, I attended those mostly aimed at the developer (wasn’t too interested in gaming or the “boring” business talks).

I could drone on about each talk and what it covered, however it’s probably best that I just highlight some of the key talks and topics I found of interest:

Implementing analytics with AspectJ

Obviously one of the main drivers of putting an application to market is generate downloads, which, if priced correctly, will create revenue. However, being able to understand what users actually do with your application could enable you to target specific features even more, and produce even more downloads, revenue, and general happiness in the development team knowing their applications are doing well.

Wouldn’t it be great if you were able to track what users are doing in your applications? Being able to see which screens, features, or even which buttons are being used most in your application? The ability to know this information would allow you to back up business decisions, and enable product managers to decide and target upon new features.

Fortunately, the Google analytics framework is able to assist us with such issues, it can be integrated into applications and you can track events where you feel necessary. Additionally, the analytics API is also cross-platform compatible, so if you have iPhone and blackberry versions of your application, you can also track statistics there too.

To read more about this, you can access the slides from the presentation here.

Innovative UI with GreenDroid

I’ve developed a few android applications in my own time, both for hobbyist curiosity, and for Smart421s’ marketing curiosity (this one is yet to be published, watch this space!), and one of the things that takes a considerable chunk of development time, is designing and implementing the UI. Quite often, the application code is incredibly simple, sometimes even less than 50 lines, but arranging the UI into something remotely usable can often take double, if not more time than the original business logic for the application did.

Fortunately for us android developers, a pioneer named Cyril Mottier has forged an API from the depths of developer frustration to help, named GreenDroid. When developing UIs, its important to make the interface responsive, smooth, fast and polished, which can be somewhat an involving task if developing manually.

GreenDroid is a library, that can be included into your applications, which you can then depend on to create clean, attractive and accessible UIs easily, without having to manually design them in XML yourself. You can read more and see examples here :

I can see a great many applications, and developers benefitting from this venture, particularly smaller scaled applications that are primarily interested in delivering functionality, without imposing corporate branding and color schemes across their application, however I wouldn’t be surprised if Cyril hasn’t already taken that into account and exposed some options for modifying color schemes and anything else to “brand” the UI.

I did try this on one of my applications that’s in development at the moment, it was incredibly easy to set up and use, if you’d like to see what this library can offer, checkout an application on the market called GDCatalog, Cyril released this as a showcase for the GreenDroid API.

Test Driving android with Robolectric

TDD is a development principle that most developers should consider, or at least be aware of. This is a practice that Smart421 actively pursue, so I was keen to see how this can be applied in the Android world.

Android applications are written in Java, however they don’t run on the standard JVM, but a mobile specific Dalvik VM, which can make standard unit testing somewhat frustrating, as the application code has to be built, the emulator started, application deployed and then started, that’s all before you can run a measly JUnit test. Fortunately for us developers, Robolectric saves the day.

Robolectric allows us to write simple JUnit test cases, against android components, which can be executed on the JVM, enabling a much faster TDD cycle. Robolectric works by intercepting android framework calls, and re-writing the method bodies, essentially allowing us to run a mocked android platform on the JVM for testing purposes.

Ultimately, Robolectric enables us to black box test, fastly, without need for mocking frameworks. I’m using Robolectric in two of my android applications and it has proven to be an easy to use API, and has helped me catch several potential issues, thus serving its intended purpose.

Other keynotes

I attended around 10 discussions over the 2 day period, here are some other talks that I found of interest.

Code reuse

Often, development teams want to release a trial, and a full (and often paid for) version of their application. Ultimately they would want to use the same code base for both versions of the application (you’d be crazy not to). There was a talk from the company TouchType on how they have implemented a build framework to disable or remove certain features from a build.

Mark Murphy’s predictions sure to go wrong

Whilst no one can predict the future precisely, Mark Murphy is quite the celebrity in the android world, so he’d be a reliable source to give us a steer in what may pan out in the future for the little green robot. Marks’ talk covered some of the things we may encounter, such as e-readers merging with tablets (which we’re already starting to see now, with the Kindle Fire), Amazon to be the #2 tablet maker (which we may also see now the budget Kindle Fire is on the way) and the inevitable introduction of ever more cross-platform technologies, hoping to obtain 100% cross-platform compatible apps, such as PhoneGap from Adobe, and pure HTML5. There will always be subtle differences in platforms and hardware, so these may prove slightly less forthcoming than hoped.

Hacking the android market for private betas

Currently, the android market doesn’t support betas, or private listings. However the devs over at LightBox have devised a way of “bending” the rules to cater for this.

Before they released their LightBox camera application, they ran a private beta on the android market, by publishing the app under an undisclosed name, locking all features, and requiring an authentication key to unlock the application. This enabled a select number of users to easily access the application, trial it, and provide feedback, without releasing the application to the wider market, for often preempted flaming from the general android community because it doesn’t play Super Mario, or because it’s not free.

I don’t know how legally correct, or even ethically correct this usage of the market is, but I found it an interesting topic of discussion.


A startup from a young Spanish entrepreneur, to develop and market an android device, created by developers, for developers. The Geeksphone project is also intended to be community driven, whereby the users have a voice and direction in the development of future productions. Geeksphone do provide one unique feature, that I found rather appealing, that users are free to develop and create their own Android ROMs, submit these to Geeksphone where they will run their own in-house tests on it, and give it a seal of approval. Users can then use the ROM without voiding their warranty, and it is fully supported by Geeksphone from then on, quite an appealing promotion to users who intend to do slightly more than checking emails, and using Facebook on their devices.

To summarise, the conference was very informative and provided a wealth of information on all things happening in the android world. I’d certainly like to attend again next year, it would also be fantastic if we could muster up some Smart421 presence on site too….

All DroidCon seminars were recorded on video, and should be freely available here :


Get every new post delivered to your Inbox.

Join 1,122 other followers