Nearly there

The picture of our Agile Wall clearly shows we are getting close to completion (of this phase at least :) Despite constantly adding new requirements based on feedback from our user sessions, all but two tickets have been completed. Not implemented are mobile alerts and content editing in the web interface, both of which are low-priority and will have to wait until the release version.

Mobile Alert Alert

One of the planned distribution channels for CloudBank content was mobile alerts, which would be pushed out to users signing up to the service and could be used with any mobile phone. This looked feasible at the start of the project based on 3rd party services available at that time, but now it seems we cannot provide this service without additional development.

Just 6 months ago the hugely popular WidSets was up an running. The service allowed users to create and customise their own RSS alert widget. It minimised network traffic by providing server-side polling of RSS feeds, and notified subscribers when new content was posted. Oficially, WidSets has since been rolled into Nokia's OVI app store, however, WidSets or an equivalent application is not available there. Looks like it just has been killed off. Why?

Plusmo offers a similar service, but unfortunately SMS alert functionality is currently only available in the US. Their standard RSS reader, without alert functionality, had an Out-Of-Memory error on out test phones (Nokia SuperNova). Another alternative, Google SMS Channels, is currently only available in India.

Faced with these facts we have to adjust our project plans. We won't offer a mobile alert service in the current beta, but we'll develop our own mobile alert service for the release version. While this will be limited in v.1 to Android phones, it can be extended in future versions to cover other platforms as well.

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.