New Adventures in Software by Dan Dyer

I haven’t seen this problem described anywhere else, let alone solved, so this post might prove useful to some desperate future Google searcher.

A couple of weeks ago I updated Rectangular Video Poker to support Honeycomb devices. In doing so I encountered a bizarre bug. The letter ‘J’ refused to display in one particular TextView. Neither the upper case or lower case variant would show, just a gap where the letter should appear. Every other letter in the alphabet displayed correctly. The problem occurred on the 10.1″ Galaxy Tab but not on the Honeycomb emulator or the two HTC phones that I tried.

The problematic TextView had a large font size (86dp) set for xlarge screens because it is used as a banner that displays the win/lose message at the end of a hand. Eventually I discovered that if I dropped the font size to 79dp the letter ‘J’ would reappear. In the absence of any explanation for this odd behaviour, making the text slightly smaller seemed to be a reasonable workaround. Why was ‘J’ the only letter affected? My best guess is because, in the default Droid Sans font, it is taller than all of the other letters. Unusually, the upper case ‘J’ descends below the baseline. The lower case variant is also taller than all other letters.

With an adequate workaround in place I ignored the issue until the other day when I encountered the same problem porting a different app to Honeycomb. This app uses a large TextView to display a number. The font size is even bigger (a scarcely sensible 142dp) and consequently none of the digits displayed. Again, the problem only manifested itself on the Galaxy Tab.

In this case reducing the font size wasn’t really an option (if anything I want to make it bigger to occupy more of the Tab’s very large screen). I did however establish that I would have to lower the size to 101dp to make the text reappear.

I couldn’t find any references to this issue anywhere online (maybe other developers aren’t as fond of massive text as I am). Eventually, due to lack of better ideas, I speculatively disabled hardware acceleration for the activity in question. Surprisingly this solved the problem. I had been following the advice given at the Android Developer Lab to turn on hardware acceleration unless you have a good reason not to, but I hadn’t realised it was the source of my problem because I hadn’t first tested the app without acceleration.

This is the second scenario I’ve discovered in which I have needed to disable hardware acceleration for an activity. It’s also necessary when you have a WebView with a transparent background.

Another day, another early train to London. Following yesterday’s Barcamp, the second and final day of Droidcon UK was for the scheduled presentations. Mark Murphy (a.k.a. @commonsguy/the StackOverflow Android guru) delivered a well received opening keynote (video here) containing several predictions of where the Android ecosystem is heading over the next 3 years.

The first of the inevitable sponsors’ keynotes saw Cisco pitch its enterprise Android tablet, the Cius. It’s a chunky 7-inch device (I’m sure they’d say “rugged”) and it only runs Android 2.2, but it represents a different approach to tablets compared to other Android device manufacturers. The main selling point is that it’s part of a fully integrated enterprise communications platform (VOIP, video-conferencing, etc.) that includes a desk phone docking station for the tablet. Later, in the afternoon, HTC touted its Android APIs for exploiting features specific to HTC tablets, such as the pen input on the HTC Flyer.

The rest of the day provided the opportunity to pick and choose from four streams of presentations. Erik Hellman from Sony Ericsson spoke about how to use hidden APIs in Android. These are features that are publicly available at compile time but explicitly excluded from Google’s documentation (via a Javadoc @hide annotation in the source). The examples were how to write code to access a device’s SMS message store and how to programatically toggle WiFi tethering.

Emlyn Howell from Accenture provided an interesting diversion with his discussion of the challenges of building in-car entertainment systems using Android. The thought of roads full of people playing with touchscreens rather than looking at the road is enough to make me never want to drive again, but apparently this danger is avoided by providing reliable voice control functionality.

One of the things you hope to get from events such as Droidcon is valuable insights that you can go away and apply to your own work. Truthfully, I didn’t really get so much of that from today’s presentations compared to yesterday or the ADL on Monday. However, there was one presentation towards the end of the day that I did find particularly interesting and intend to explore in more detail. James Hugman presented Kirin, a new JavaScript framework for developing cross-platform mobile apps with truly native user interfaces. The UIs are developed using the platform’s standard tools and then bound to the application logic written in JavaScript. This avoids the UI compromises of PhoneGap and Titanium Appcelerator while eliminating the duplication of logic that occurs with a strategy of 100% native apps for each platform.

Following on from the Android Developer Lab on Monday, I was in London again today for Day 1 of Droidcon UK. The first day of this two-day event is a Barcamp followed by a Democamp in the evening. This is a round-up of what I experienced in the Barcamp sessions (I didn’t hang around for Democamp, opting instead for an earlier train back to darkest Kent).

I hadn’t attended a Barcamp previously so I wasn’t entirely sure what to expect. In the end there was nothing particularly novel about the format, at least in the sessions I attended. After the initial pitching it was just a series of speakers delivering pre-prepared presentations like at any other conference.

10:20 AM – Terence Eden (InMobi)

I’m interested in finding out how to make money more effectively from ad-supported apps (my limited efforts with AdMob have not exactly been lucrative), and in the pre-presentation pitching session Terence was the only person to offer a monetary incentive to attend his talk (in the form of free InMobi advertising credit). Terence made two key points. Firstly, developers really should make sure that their apps are internationalised. Free apps can generate lots of ad revenue in countries like Japan and Indonesia if they are available in the local language. Secondly, app revenue is recurring. For apps that have a long lifetime, monetising using ads can be better than charging for the app in the long term.

11:00 AM – Ashay Padwal (Vserv)

Another mobile advertising talk. Vserv offers a system whereby ads are tacked onto the beginning and/or end of an app rather than intrusively within the main flow of the app. The technique used to implement this does not require any coding, it’s a modification made directly to the APK file. Vserv also provides mediation services to simplify dealing with multiple ad networks (this is presumably similar to AdWhirl).

11:40 AM – Cyril Mottier (GreenDroid)

I met Cyril and spoke to him briefly at the start of the day. He is the author of the GreenDroid library. I’d been aware of GreenDroid for a while but not had a chance to take a proper look at it. GreenDroid provides an ActionBar implementation for non-Honeycomb devices, a view pager, an asynchronous ImageView and other components for building compelling Android UIs. Cyril’s talk also covered techniques for ensuring that your Android GUI is responsive (e.g. using Handlers/AsyncTasks/IntentServices to perform background processing as appropriate).

12:20 PM – Chetan Padia (TouchType)

Chetan spoke about how the developers at TouchType (makers of SwiftKey) solved the problem of building multiple variants of their software from a single codebase. I was interested to learn about their approach as I have made my own attempts at doing something similar. The TouchType team’s approach is more sophisticated than mine and uses a combination of Ant and Python to manipulate their codebase. Part of this involves Java code generation. Chetan mentioned that TouchType is considering open-sourcing its build tool.

2:00 PM – Joe Moore (Pivotal Labs)

Joe spoke about Cloud To Device Messaging (C2DM). This is something I hadn’t done any reading about previously but I was interested to find out about (just how does the GMail app on my phone notify me of e-mails so promptly?). C2DM’s push messages are in most cases a superior option to polling, assuming that you control the server as well as the Android app (requires Froyo or later).

2:40 PM – Nicolas Klein (DataDroid)

Nicolas is another developer I had a chance to speak to early in the day. He told me about DataDroid and then said he wasn’t going to be giving a talk on it. He did give a talk on it. DataDroid provides a framework for managing data locally on the device and for performing REST web service requests to retrieve remote data.

3:20 PM – Martin ??? & Friedger Müffke

Martin and Friedger spoke about NFC. I don’t have a specific interest in NFC but the other talks at the same time didn’t appeal so I thought I’d listen to this. There was the usual mention of mobile payments and train ticketing, a brief demo of reading an NFC tag using an Android Device and some discussion of the other possibilities for NFC.

4:10 PM – Suzanne Nguyen (Immersion)

Again, I wasn’t especially concerned about haptics at the start of the day but this seemed more interesting than the other talks at the same time and, more importantly, I didn’t have to move from my seat after the previous talk. Suzanne spoke about how, using Immersion’s SDK, you can do more with haptic feedback than just basic buzzes. This is best demonstrated by Immersion’s free app that generates these various stimuli.

4:50 PM – Jouko Kaasila (Bitbar)

Jouko provided an overview of the tools available for testing Android apps. These included the Android SDK’s Monkey and monkeyrunner, Robotium (which is apparently like Selenium but for testing Android apps), Roboelectric (simplifies unit testing of Android apps by allowing code that uses the Android APIs to be run inside the standard JVM), and Bitbar’s own Testdroid.

This morning I took a brutally early train to London in order to arrive in time for Google’s Android Developer Lab at 8:30 AM. Developing Honeycomb applications for tablet devices was the primary focus of this gathering (around 30-40 Android developers attended) and Google’s affable developer advocates Nick Butcher and Richard Hyndman were our hosts.

Honeycomb

Honeycomb has been on my radar since it was launched back in February but until today I hadn’t got much further than reading the overviews of what it means for developers (e.g. fragments and the action bar) and briefly playing with the painfully slow emulator.

One reason for my lack of Honeycomb activity is that the usage figures are still very low compared to non-Honeycomb devices (Honeycomb runs on just 1.4% of Android devices according to Google’s most recent figures). Today these devices are all tablets of one type or another but Nick cautioned against developing apps with the mindset that Honeycomb = tablets. The Honeycomb APIs are coming to phones with Ice Cream Sandwich (the next major Android version). ICS is apparently informally known as “Honeyphone” within Google, reflecting its focus on reunifying the two streams of Android by bringing Honeycomb’s innovations to phones.

Of course, some of Honeycomb’s features, such as fragments, are already available on devices running Android 1.6 or later via the Android Compatibility Library. Following on from this, another of Nick’s key points was that, whether you are targeting phones, tablets or both, if you are developing Android apps today and you are not using fragments then you are doing it wrong. Fragments are central to Honeycomb, fragments will be central to Ice Cream Sandwich, and fragments are already available (through the compatibility library) for all Android versions back as far 1.6 (Donut).

Android Market

The topics of the day were not all Honeycomb-specific. Richard provided a lot of useful and interesting information about the Android Market. One of the facts that stood out for me was that 7 of the top 10 highest grossing apps on the Market are not even paid-for apps, they are free apps that incorporate in-app billing. If you haven’t considered the in-app billing model for monetising your apps, you could be missing out.

As part of the Market discussions there was a lady in attendance (whose name escapes me, sorry) from the team responsible for the Android Market publisher console. She was collecting feedback to help guide future improvements. There were a lot of good suggestions made.

Richard also gave us the latest figures for Android device activations. There have now been over 150 million total Android device activations and this is increasing at the astonishing rate of 550k per day.

Porting Apps to Honeycomb

There are two very straightforward things to do first when updating an existing app to run on Honeycomb-powered devices. Both involve minor changes to AndroidManifest.xml. Firstly you should set android:targetSdkVersion to 11 or higher. This declares that your application is Honeycomb-aware and will result in it being given the Honeycomb default holographic theme.

The second thing to do is to turn on hardware-accelerated graphics. You need to test your app after enabling acceleration as there are some scenarios that might be problematic, such as custom drawing code, but for the vast majority of apps it is a free performance boost.

As for the frustrations of the very slow Honeycomb emulator, changes are afoot that will address that. In the meantime, Samsung furnished those developers fortunate enough to be present at the Android Developer Lab with a very agreeable alternative to using the emulator.