Android fragmentation

In a recent blog post titled Android: write once, debug on every handset thats out there Hartmut Seichter complains about incompatibilities in the Android Camera API. As we found out last Monday when handing out our new T-Mobile Pulse phones to students taking part in the CloudBank evaluation, these issues are not limited to low-level APIs but even occur at the highest levels: the behaviour of Intents (re-usable software components in Android).

The CloudBank app uses a standard Android Intent to record audio. As this is part of the core Android API and behaves consistently on all HTC phones and SDK emulators across different Android versions, we did not even think of testing audio recording on our T-Mobile Pulse phones. Our students however jumped straight into it and found that there was no way to use a recording and go back to the CloudBank app.

Behaviour after recording: left Android standard, right T-Mobile Pulse

It turns out that either T-Mobile or Huawei, the manufacturer of the phone, have customised this Intent: Instead of showing "Use this recording" and "Discard" buttons after recording, the Pulse does not show any buttons at all but instead has options like "Share" and "Set as Ringtone" hidden in the menu. Congratulations T-Mobile/Huawei, you just have broken every app out there using the sound recorder intent on your phone!

On a technical level, the return values of the Intent were screwed up accordingly and it took us two whole days to find a work-around for Pulse phones that mimicked the standard behaviour and made sense to users! (Well, at least half of that was spent on getting the Pulse to work with the Android Debugger Bridge, but that's another story...)

Content monitoring and moderation

Once the application is released and user numbers pick up, some users will inevitably post spam or otherwise inappropriate content. While screening every single contribution can be a full-time job, most user-generated content systems adopt a more lightweight approach where monitoring and moderation is delegated to the community. Following this approach, the CloudBank app now has functionality for users to flag content:

1) Someone might find this entry inappropriate


2) Click in the Menu button to bring up menu options


3) Hit the Flag entry menu option and tick a reason


4) The item is now flagged for everyone to see (red flag top right corner)


5) The flagged item is easy enough to spot for an administrator...


6) ...who then can look at the entry, edit it, reset the flag or delete it from the system.

Updated application and support docs

Please update CloudBank on your mobile phone to version 1.1 as we made some changes to the public API that break the prototype you might have currently installed.

The mobile user guide, API specification and RSS feed have also changed:

CloudBank app v1.1
http://itrg.brighton.ac.uk/download.php

Mobile user guide v1.1
http://itrg.brighton.ac.uk/cloudbank/files/CloudBank_Mobile_User_Guide_v1.1.pdf

CloudBank Public API v1.1
http://itrg.brighton.ac.uk/cloudbank/files/API_v1.1.pdf

New CloudBank RSS feed
http://itrg.brighton.ac.uk/cloudbank/rss.php

User groups or Tags?

One of our aims was to ready the system for use in different contexts and thereby make it more sustainable in the long term. To do this we planned to implement 'user groups' which would allow the creation of distinct learning spaces, e.g. to allow a group of students to start with an empty word list and only see content contributed by group members.

On closer inspection however, user groups have a considerable admin overhead - and they are not the only way forward to achieve separate content pools. A light-weight alternative are tags or 'hashtags' or 'channel tags'. Tags have no admin overhead at all and in many ways seem a more elegant and flexible solution.

On August 23, 2007, the Twitter hashtag was born. Invented by Chris Messina, the first tweet with a hashtag read as follows: “how do you feel about using # (pound) for groups. As in #barcamp [msg]?”

Source: The Short and Illustrious History of Twitter #Hashtags

Drawing up a list of real world problems / use cases and spelling out how these would be addressed with user groups or tags, we found that most problems could be addressed with both solutions (the main difference beeing the admin overhead for user groups). The only case not covered by tags is when groups want to keep their content private, however, this is balanced by the difficulties of usergroups to share their content with others. It all boils down to tag-based systems being by default open while user-groups are by default closed (even if you can easily join). Confronted with this almost philosophical questions we decided to implememnt a tag-based solution.


In order to cover all use cases, we need to be able to show all content, show only content from one or more subsets and exclude content from one or more subsets. Consequently the Settings dialog has these options:

• Show only these tags: Only content tagged with these tags will be visible when browsing (e.g. group tag). Leave empty for all content.
• Don't show these tags: Exclude certain tags when browsing (e.g. sex, religion). Leave empty to not exclude any tags.
• Default tags for my posts: Add these tags by default (e.g. group tag). Leave empty for no default tags in your posts.

Here's a use case:
A teacher at the ISC wants his students to start from scratch with an empty word list. He thinks up the unique tag ISC2010 and instructs his students to call up the Cloudbank Settings dialog, where they enter the tag as an inclusion filter('Show only these tags: ISC2010'). In addition, students enter the same tag as their default post tag('Default tags for my posts: ISC2010'). As a result, all content posted by students is tagged with ISC2010 and they only see CloudBank content tagged with ISC2010.

New app, tools, blog

You may have noticed the new menu bar just below the blog title? It sums up the latest development spurt to get CloudBank ready for prime time - as a sustainable and widely-used mobile language learning tool.

We now support dynamic user groups, not through a boilerplate user-group implementation but through rather sophisticated tagging support that enables teachers to set up ad-hoc content pools and gives learners fine control over what they see.

We addressed the issue of spam, offensive and wrong content by enabling users to flag items for review by a cloudbank administrator or editor (e.g. a teacher using the system)

We added context-sensitive online help to the mobile application for novice users, as well as an about screen and a settings menu.

We created an admin panel which enables non-technical staff to edit, follow up flagged items and delete content from the database.

Last but not least we prepared our shiny new Android phones for action, by un-doing the useless t-mobile default configuration, setting up reasonable settings and homescreen and installing the new Cloudbank app. This may sound like childs play, but in fact I had blisters on my fingers after configuring 8 phones via touch screen!

I'll be explaining each of these points in more detail over the coming days. But now it's off to deliver the phones to the ISC so that we finally can get on with our evaluation...

CloudBank on the phone

This week was all about getting CloudBank to run on actual phones. Pushing apps from the development environment onto the phone is a fairly straightforward process described in detail in the Android developer documentation.



Almost inevitably hitherto unnoticed bugs will appear once an app runs on a real device. Among the many possible causes for unexpected behaviour is forgetting to change localhost references to the real server on the web! To automatically deal with this one needs to find out if running on a device or emulator, which seems essential in many ways but strangely is nowhere documented.

import android.os.Build;

public static final boolean isEmulator(){
return Build.MODEL.equals("sdk");
}

The android.os.Build class holds all kinds of information about the platform we're running on. I picked the MODEL field, which gives me "sdk" on the emulator and "HTC Magic" on the phone, but you might replace that with whatever you see fit.

First prototype

Based on the user interface described in the previous post, our first prototype has four primary screens for start-up, browsing, viewing and editing content.



The Android client runs on the emulator, communicating with a REST server on localhost.

Users' calls for a quick application start-up and a personal dictionary led us to maintain a local cache of items that were added or edited by the respective user. Content in the first screen is retrieved from a local SQLite database on the handset for quick start-up. Content in the Browse and Detail screens is retrieved from a MySQL database on the server. A database abstraction layer keeps the code clean and takes care of all caching, synchronisation and server communication issues.

User Interface

As Lyn described in a previous post, our users' ideas about CloudBank are in many ways different from our original idea. While the initial design focused primarily on collecting and sharing content, users emphasised browsing and filtering content already in the system. Other high priority requirements were a quick application start-up, support for links to online content and a personal dictionary mode.

The Balsamiq mockups below show how we translated these requirements into four application screens in the CloudBank app:



Clockwise from top left: 1) Welcome screen with 'personal' list of content items contributed or edited by this user. 2) Edit screen to enter and edit content, with sub-activities to take a picture, record audio, add link to online content. 3) Detail screen for list items selected in (1) or (4), with direct option to edit the content. 4) Browse screen with all content items and options for full-text search and tag based filtering.

Android XML parsing

CloudBank communicates with a REST server to read/write application data from/to the cloud. As our server speaks XML, we need to parse XML on the Android client. However, a quick look at the documentation reveals that Android has no less than three different XML parsers: the traditional DOM and SAX parsers plus the recently added XML Pull Parser, which promises to deliver high performance at a small memory footprint.

Great, this is exactly what we want: higher performance with less memory!

But does the promise hold up? Too lazy to set up my own performance test and confident that others have done that already, I dug up a recent article on Android XML parsing by Shane Conder. It describes a performance test for all three parsers with different data volumes, which surprisingly found the SAX parser to perform best on all three data sets.