It’s time to get groovy when building android projects

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 Meetup.com 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 meetup.com 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.

 

IBM Worklight, making light-work of app development in the enterprise

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/defaults.properties">
 <classpath>
 <pathelement location="./build-config/worklight-ant.jar"/>
 </classpath>
 </taskdef>
 <property environment="env"/>
 </target>

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"/>
 <adapter-builder
 folder="./adapters/TwitterAdapter"
 destinationfolder="./bin"/>
 <!-- Build your other adapters here, same as above-->
</target>

<target name="deployAdapters" depends="init">
 <property name="WLSERVERHOST" value="http://my_aws_ip_here:8080/SmartConf"/>
 <echo message="Deploying all adapters"/>
 <adapter-deployer
 worklightServerHost="${WLSERVERHOST}"
 deployable="./bin/TwitterAdapter.adapter"/>
 <!-- Deploy your other adapters here, same as above-->
</target>

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"/>
 <war-builder
 projectfolder="./"
 destinationfolder="./bin"
 warfile="./bin/SmartConf.war"
 classesFolder="./bin/classes"/>
</target>

<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"/>
 </war>
</target>

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"/>
 <app-builder
 applicationFolder="./apps/Smartconf"
 nativeProjectPrefix="SmartConf"
 outputfolder="./bin"/>
</target>

<target name="deployApps">
 <property name="WLSERVERHOST" value="http://my_aws_ip_here:8080/SmartConf"/>
 <echo message="Deploying all WL Apps"/>
 <app-deployer
 worklightServerHost="${WLSERVERHOST}"
 deployable="./bin/SmartConf-all.wlapp"/>
</target>

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"/>
 </target>

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 strange, 5.0.0.270 = v5.0 GA, but the developer edition is 5.0.2.407-developer-edition = 5.0.0.3.
• If you have an existing 5.0.0.2 WL server installation, don’t upgrade it to 5.0.0.3, 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.

Conclusion

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.

 

DroidCon UK 2012, NFC is definitely the coolest kid on the block

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.

Fragments

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 :

• Sqlcipher – encrypted data store on the device
• Google GSON – similar to json, pojo in, json out.
• Anything by commonsware – ’nuff said
• Pulltorefresh
• Android assets studio – Icons, tabs, notification icons etc.
• Roboguice – dependency injection with Guice

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…

 

DroidCon UK 2011: Two Smarties, and a whole bunch of freebies…

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 : https://github.com/cyrilmottier/GreenDroid#readme

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.

Geeksphone

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 : http://skillsmatter.com/event/os-mobile-server/droidcon-2011