Droidcon London 2011

Droidcon UK 2011

This year, we had the opportunity to go to the Droidcon in London, a great conference about mobility and Android. The two-day event was organized like in 2010: a barcamp the first day, and conferences with great speakers the second one. Main topics were user experience and interface, Android development, mobile apps business and distribution.

User eXperience

The number of Android users has incredibly risen! More than 300 000 applications can be downloaded on the market! What makes your app better and prevent it from user rejection ? Look and feel and responsiveness, of course!

 

Make your application smooth!

This year, Cyril Mottier talked about UI and gave pieces of advice to develop pretty and fluid applications. It starts with a simple order: do not block the UI thread because it is the one that displays elements on screen and handle interaction with the user. Using it for non UI process leads to slow animations, laggy interface and if five-second freeze occurs: Application Not Responding messages!
Android SDK offers several ways to handle secondary threads for non UI processes: execute it with simple Threads and Handlers (maybe with a Looper to do operation queues), create an AsyncTask or even launch a dedicated service with the IntentService class.
Likewise, access your data asynchronously: AsyncQueryHandler, Filter and SharedPreference.Editor.apply() can help you.

 

Use great components

All recent successful applications understood it: nice and customized views are the key! Cyril Mottier’s open-source library GreenDroid is one of the most known. It allows you to ease development by using its theme and numerous features for pre-Honeycomb application (and after with compatibility package): ActionBar, AsyncImageView, PagedView, QuickActions and more!


GDCatalog application is available on the Android market to demonstrate the capabilities of this very useful library.

 

Follow Google best practices to optimize your app for smartphones and tablets

ActionBar

Nick Butcher introduced some guidelines to design UIs for both kinds of devices. The most noticeable UI Pattern that has become unavoidable is the ActionBar. Its aim is to help the user accessing screen details and contextual actions. This action bar places elements in a way to help user interactions. See GMail example below.

On the left side, the application icon informs the user where he is. As on a website, a click on this button leads to the application main screen. A second way to navigate inside the application flow is offered by the in-app navigation button. This action can be different from traditional Android back button. The right side presents traditional application parameters button and contextual actions. More contextual informations can be added to the bar under certain conditions (items selection, etc.).

To implement an ActionBar on pre-Honeycomb Android version, you can use Google I/O application implementation, ActionBarSherlock or previously presented GreenDroid libraries. Upper versions (v3+) can use SDK ActionBar.

With the upcoming Ice Cream Sandwich version, ActionBar will be able to automatically layout the interface for phone or tablet. Little advice for this: provide text and icons for each Action item and set for each one the flag: showAsAction=“ifRoom|withText”.

Multi-pane layouts

Since Honeycomb, a single APK can be executed on both smartphones and tablets. On large screens, it is preferred to display more complete content than a simple ListView. With Fragments, it is possible to aggregate your code to use it on 2 smartphone screens and a single tablet screen. With this concept, you can imagine a lot of different screen dispositions depending of screen sizes, orientation, etc. We will talk about this subject in a next article.

Fragments usage

Do’s and don’ts

Simple tips were given to improve development:

  • aim for a single APK for both tablet and handset devices
  • use compatibility library
  • customize every view to represent your brand
  • support both landscape and portrait modes
  • extract dimensions for phones and tablets (e.g. values/dimens.xml and values-large/dimens.xml)
  • use themes and styles to reduce code redundancy
  • enable hardware acceleration

And other to avoid in your application:

  • do not use small fonts
  • tablets are not “big phones”: they fulfill a different need and require special layout optimizations
  • do not assume that a device running an application with API level >= 11 is a tablet: Ice Cream Sandwich is coming for both tablet and phones!
  • do not assume that all tablets have an xlarge resolution: 7” tablets have a large resolution! Detect tablets with the minimal width your application needs, generaly 600 dp:

 

         <manifest ... >
              <supports-screens android:requiresSmallestWidthDp="600" />
              ...
         </manifest>

 

A bit of technique

Testing

You may have seen comments such as “Doesn’t work on SGSII” or “Force close on HTC Wildfire” on Android Market. Indeed, with no less than 300 phone models, it is difficult to provide an application that works on each device. The best way to minimize bugs is to test your application. You can do it manually or with low cost outsourced hands but the best way is to automate your tests.

Android Test Frameworks

Several frameworks exist and cover different kinds of tests:

  • Monkey, which ensures to simulate random actions on the UI (buttons, textedit, touch…). This is a good way to validate the robustness of the application.
  • The Google test api (instrumentation) which can be laborious to implement although essential if you want to test the interface behavior.
  • Robotium, a good testing framework, that simplifies the test writing over the Google’s instrumentation tests.

We also came across two other frameworks (plateforms):

  • Robolectric comes with a great advantage over robotium and instrumentation: you don’t need an emulator to test your application, and everyone knows how much the emulator is slow! So, you run your tests in a standard JVM, in your favorite IDE and you gain a lot of time. Joe Moore (from Pivotal Labs) made a demo with a set of 20 tests. The standard instrumentation test took 45s on an emulator (already launched, so you can easily add one minute for the launch) while robolectric got the job done in only 12s! Moreover, it is very simple to use, simply add @RunWith(RobolectricTestRunner.class) on your test classes and that’s it! Give it a try, it’s free. You can get the slides here.
  • All the previous solutions are either boring to implement (manual creation of the tests), nor realistic (emulator, JVM). Testdroid (developed by Bitbar) promises to answer to both issues with two services:
    Testdroid recorder, an eclipse plugin, ensures to capture your test while you execute the application. It generates robotium code, so you can replay the tests after.
    Testroid server is a cloud platform that allows to automatically execute the recorded tests on multiple Android physical devices. A lightweight DeviceAnywhere? Seems promising to test your applications on real devices, on different Android releases, with different form factors…

 

Do Not Repeat Yourself

In our projects, a lot of tasks are repeated. The session “Kick-starting Android Application Development” presented some interesting projects to improve Android development:

Android plugin for Gradle project allows to use Gradle to reduce time spent on APK build, packaging, integration, etc. It can be use in integration with Maven or Ant and also allows to create Android applications in Scala.

Roboguice, is a Google implementation of Guice to use dependency injection. It uses reflection to inject fields at runtime and allows to get rid of resources initialization, service creation,… A simple demonstrative example to get a TextView instance: @InjectView(R.id.name) TextView nameTextView;
Another similar project (AndroidAnnotations), based on subclass code generation instead of reflection, allows to inject content with no runtime impact on performances.

 

Application distribution

Several sessions were related to application distribution, and how to improve your application and its ranking on the Market. Here are some tips from Caroline Lewko (Wireless Industry Partnership), Thai Tran (LightBox) and Konstantinos Polychronis (Bugsense).

 

Do not forget marketing!

Nowadays, publishing an application and keeping it visible on the stores is a challenge. WIP shared several tips to make your application successful through time. First of all, as mobile is growing fast, you have to follow the same rule! A way to move at same speed is to make short Agile development cycles and for each, a marketing review of the product. Marketing’s role is to ensure that the application always fits the market’s needs, try different implementations (A/B testing). It keeps the product uptodate and brings opportunities to “fail fast” instead of achieving a useless application.

Once you have a product that grows fast, you have to make your customers like it! It starts with a good name. Use Google and social networks to find a name that will be easily adopted by the public. Then use those social networks, especially Twitter and Facebook, to make your name and your product known. The more it is known, the more it will be downloaded and visible on stores.

 

Beta test your application

Once you have developed it, and tested it, go to beta test. You can do it yourself, recruit some beta testers, send them the apk and get their feedback. You can go further, put your application on the Android Market and automatize feedback.

On the market, make your application the less visible possible: do not use your usual account, do not provide description, screenshots, keywords, use a different package name in the application to reset comments and notes when you will deploy the release, provide an invitation code to your beta testers.

Another solution, easier, is to get a service like Appaloosa to distribute your apps to a managed range of users. We got the opportunity to show this product during the barcamp and make a demo, which was well welcomed. We really felt the need of such a solution.

Appaloosa

Get the maximum of feedback

In order to ensure customers engagement: give them a way to provide some feedback and use that data to improve your product’s features.

You can use frameworks like ACRA or Bugsense to retrieve crash reports (which phones and characteristics, which os version, what kind of error). Be sure to correct bugs after that.

Use Google Analytics or Flurry Analytics to get usage metrics (how many users, how many time, what features usage). Collect the maximum of information to improve your application navigation.

 

Use Android Market tools for developers

To conclude the conference, Richard Hyndmann from Google talked about developers facilities on the Android Market and how to get visible on it. To be at the top of rank, your app has to be fit and polished. Of course, avoid straight port from other plateform, it generally causes users rejection. If your application offers unique features for Android, it is more valuable and will be rated as so. Seasonality also assures regular update of your app’s position that can appear in several different categories like Top Free & Paid apps, top grossing apps, and others. Also, do not forget to provide new format images for add banner: it is a great way to get downloaded!

The Android market offers a new functionality: distribution of multiple APK. It allows a developer to provide different APK files for different kind of devices. For example, one application for handset devices and another for tablets. It can simplify adoption of new platform features and lighten your apps. However, Google advices to use this feature only in special cases and always prefer a single APK file when possible.

It appears that Honeycomb users are ready to pay for applications! It can generate some big revenues. Some attention was given to developers ways to make money. In-App Billing system was presented. It is another way to sell virtual content such as additional levels for games or download files. Fees are the same for in-app purchases as the transaction fee for application purchases on the market: 30%.

In app purchase

Another tool that can be useful to prevent piracy for paid applications on market is Licensing service. Its License Verification Library (LVL) allows your application to set up licensing status protection. The last feature presented is application Data Backup. Implement it to offer users to save application content and preferences, even private files in the cloud. All the data can then be restored, for example when switching to a new Android device. All these tools can be used to make your applications better! Just think to use them.

 

What’s next?

We want to finish with some interesting predictions given by Mark Murphy during the opening keynote:

  • In 3 years, 1 application over 3 will be developed using cross platforms tools such as HTML 5 (with Phonegap or Rhodes), app generators (Appcelerator) or any other framework that could come to provide multi-platforms apps. Indeed, most companies want to provide their apps to the maximum of platforms with the smallest development cost. We even think it could be more than 1 over 3 applications…
  • In 3 years, Amazon will be the second tablet manufacturer (after Apple). The new Kindle Fire offers today a full multimedia experience on an Android based system. Will Amazon still be using Android plateform in the following years ?
  • In 3 years modded roms will be significantly more popular! Modded roms like CyanogenMod could diversify and meet enterprise needs in terms of security and professional tools… This is, with the rise of private application stores, one of the major points that may make Android become an important actor in enterprise.

DroidCon 2011 was a great time for us, we learnt a lot, especially that next year will be tablet year! Ice Cream Sandwich is coming and will give the opportunity to develop applications for both devices kinds. Be ready and always make better products!

Thanks to organizers and sponsors for this year.

Sponsors  HTCDev

Keywords: , ,

Leave a comment