Posterous theme by Cory Watilo

Calling Javascript from native, a usability question.

I’ve been thinking about the mechanics of calling javascript from native and how to make it as nice as possible for native developers.

I was going to ask this to just the developers at Future Platforms who are working with Kirin at the moment, but thought it applicable to any interested developers: so I spun it out into a blog post.

In the spirit of “APIs as UIs for developers”, I’m treating this as a usability question.

What is happening now, for contrast:

In the UIViewController’s viewDidLoad method, a kirin helper is made, binding a native object to the named javascript module. In this case, it’s MyScreen, which corresponds to a javascript file MyScreen.js.

self.kirinHelper = [KIRIN bindScreen: self withModuleName: @"MyScreen"];

The KirinHelper method provides a number of methods, including calling and cleaning up callbacks into javascript and calling methods on the javascript module. It also provides access to a dropbox, and in some cases the current UIViewController.

Once the kirinHelper is constructed, you can call methods on the javascript module:

[self.kirinHelper jsMethod: @"fooMethod"];

which will call a method in the MyScreen.js module:

exports.fooMethod = function () {};

Calling methods with arguments is a little more work. To call method:

exports.barMethod = function (myBoolean, myNumber, myString) {};

For three args it boils down to:

[self.kirinHelper jsMethod: @"barMethod" withArgsList: @"true, 2, 'string'"];

There are helper methods, but they only make it safer, not more readable or writeable:

[self.kirinHelper jsMethod: @"barMethod" withArgsList:
                        [KirinArgs args:[KirinArgs bool: YES],
                                               [KirinArgs integer:2],
                                               [KirinArgs string: @"string"],
                                               nil]];

[KirinArgs args:] is a va_args method, concats the strings together into the form above. Each of the other KirinArgs methods transforms an objective-c type into a string representation usable by javascript. Also supported are NSDictionarys and NSArrays.

There is also a method in KirinArgs called taintedString which URL encodes the string before quoting it. This if for strings from the user that may contain “ or ‘ characters.

What I’ve tried, but haven’t been able to do:

[self.kirinHelper jsMethod: @"barMethod" withArgsList: YES, 2, @"string"];

This will work when literals are supported, but not just yet: YES and 2 are primitive types, which don’t work with va_args.

This would work for Java, because of auto boxing and varargs:

mKirinHelper.jsMethod("barMethod", true, 2, "string");

Both would simplify things at the call site, though would provide no additional compile time safety. They don’t have any intrinsic support for tainted strings either.

What I’m proposing, and asking feedback for:

self.kirinHelper = [KIRIN bindScreen: self withModuleName: @"MyScreen" andProtocol: @protocol(MyScreenProxy)];
self.myScreen = (id) [self.kirinHelper proxy];

The self.myScreen is an instance of NSProxy which forwards any calls to javascript. The MyScreenProxy is a protocol which declares in Objective-C the javascript methods that will be called:

@protocol MyScreenProxy
- (void) fooMethod;
- (void) barMethod: (BOOL) myBoolean : (int) myNumber : (NSString*) myString;
@end

Calling:

[self.myScreen fooMethod];
[self.myScreen barMethod: YES : 2 : @"string"];

Feasibly you could use named arguments too:

- (void) bazMethod: (NSString*) name withOptions: (NSDictionary*) dict;

but there would have to be a simple mapping between that and javascript:

[self.myScreen bazMethod: @"string" withOptions: options];

which would naïvely map to:

exports.bazMethodwithOptions = function (name, dict) {}; // note non camel case

A more involved mapping may solve this camel casing problem, but I expect most uses would avoid named arguments.

In Java (for Android) this would be and in all likelihood use the java.lang.reflect.Proxy object:

mKirinHelper = mKirin.bindScreen(this, "MyScreen", IMyScreen.class);
mMyScreen = mKirinHelper.createProxy();

mMyScreen.fooMethod();
mMyScreen.barMethod(true, 2, "string");

Questions:

Most of these questions will be answerable by people who haven’t used Kirin in its current form (i.e. on the kirin-fragments branch) but who are familiar with the intentions of Kirin. I have also included Android versions that may help those who don’t speak Objective-C.

  • does chore of maintaining of a protocol outweigh the benefit of type safe calls into Javascript?
  • is the language of proxies and protocols clear in its intention?
  • Is this the best way of calling from native to javascript?
  • How do you call strings that are “tainted”, i.e. may contain ‘ or “ characters? Is there an automated (and nice way of doing it);
  • Can we get rid of the helper method altogether, or combine the helper with proxy? Is it desirable? If so, how do you call callbacks? How do instantiate the combined object?
  • Any additional thoughts?

Lazyweb: Git on Android

I did a tweet the other day that I thought should be expanded upon:

Dear the googles, please could you add an implementation of Git or Hg to a future Android? Be awesome kthxbailuv me / cc @crafty @tornorbye – James Hugman (@jhugman) January 20, 2012

I was thinking principally about embedding Git: JGit is written in Java, so could be bundled into an app, or use the NDK to compile CGit; however it occurs to me that Mercurial or Bazaar might serve just as well. Edit both Mercurial and Bazaar are python based.

I’m sure that this is not a new idea – it’s likely to be a fairly obvious idea. What I’d really like is an API for any app to use to push to and pull from arbitrary repos across the internet.

  • BackupAgent on steroids, onto a server controlled by the app developer.
  • Data synchronisation. Sync my data on to all my devices. iCloud without the single point of failure.
  • Configuration management of all installations of my app. Puppet used to use a CVS repo for this purpose.
  • Fairly easy implementation of “Undo” or “Revert” type functions.

An interview with a Googler on HTTP ETags (I can’t find it anywhere) suggested that they (Etags) could be used to turn the whole internet into a cache or CDN for your app. A distributed SCM could do the same for syncing.

Because these tools already exist, there’s a plethora of support libraries and APIs to use on the server and desktop:

  • Drop content in at the server’s copy of the repo, and it spreads out to all devices. e.g. Kindle book distribution.
  • Perform calculations on the server and push the results out the user’s clients by committing the the user’s repo. e.g. [Tweeted Times] (http://tweetedtimes.com)
  • Webapps that integrate well with your devices.

As a fairly unimaginative soul, I’ve only touched on the most obvious use cases I could think of; I’m sure that such power could be wielded with much greater ingenuity.

Indeed, I would expect the likes of Parse to be all over it.

Unfortunately, I don’t think it’s ever likely to happen:

  • The Gears team were reluctant to provide a syncing API, as they couldn’t provide a one-size-fits all solution.
  • Engineering time – I haven’t done enough research to find out how much work it would be, or if there needs to be any restrictions needed to be implemented. I know AGit took about a year to produce, but that also includes user-interface work.
  • Strategy reasons. This may compete with existing Google provided solutions. I’d also like to see MQTT in Android, but it competes with C2DM. Who knows, though, it could already be an existing 20% project.

I hope I’m wrong: it would provide a substantial response to iCloud, but without having to pay for server infrastructure.

Work in Progress: In the Kirin Pipeline

We launched Kirin over the autumn of last year. For those who don’t know (which is most people), Kirin is a set of frameworks for writing cross platform native mobile apps.

I introduced Kirin to Over The Air, DroidCon London and DroidCon India by telling the story of how we wrote the now award winning Glastonbury 2011 app for Android, Qt and iOS.

Over the last 12 months we’ve gone from “That’s crazy, but it might well work”, through “Holy kaw, we’re doing it” to “it works, we should tell someone” and finally “if we could do it again, what would we change”.

Over the last three months or so, I’ve spent quite a bit of time asking folks who have looked at Kirin, some just a kick of the tyres, some been forced at knife-point to actually build something. Here’s what they’ve said:

  • getting started is way too hard.
  • there are too many dependencies
  • there is little or no documentation
  • there seems like there are many things to do, but I don’t know what they are.
  • there’s too much exposed, and the “API” for what it is, is not very well defined.
  • Android Fragments aren’t supported. There’s no point if fragments aren’t supported.
  • There’s a lot of Javascript. Does it have to be in Javascript?

Over the last month, we’ve started addressing these issues.

Now, I’m not ready to announce a big release, but I’m excited enough about what’s happening for me to talk about it now.

First off:

Modularizing the build

The aim of this piece of work is to minimize the number of dependencies you need in order to ship a product.

This is more of a problem than it sounds: there is a real cost to some of the dependencies.

  • iOS and Android both ship with SQLite. WP7 has a database, but it doesn’t speak SQL. We would likely need to ship SQLite for WP7.
  • Twitter and Facebook SDKs aren’t needed for many projects, so why is the Facebook SDK a requirement for Kirin on Android?
  • We don’t want to be the only ones able to add things into the Kirin codebase.

If we can make some parts of Kirin optional, then we can reduce the barrier to entry for new users, and at the same time giving a route to more advanced developers to extend Kirin in ways we haven’t thought of.

Part one of this work is now done: a spiffy new build script (I hesitate to call it a system), which gathers the Javascript together from the application, kirin-core and any plugins. The build is designed to be a little bit extensible, and we are also running native compilation through this as well.

It turned out that Javascript was a good language to write this in, and I made extensive usage of node.js’s fs and child_process modules.

Part two of this work will involve working out how to glue these so called plugins together. From a native compilation and project setup point of view, as well as a runtime configuration point of view.

Retooling for Android Fragments

Funnily enough, client needs mean that the fist thing to be done was for iOS.

However this is a hugely significant piece of work because it very much cleans up a lot of issues of code quality, object lifecycle, and leaky abstactions.

This work is mostly done for iOS now, but makes the previous incarnation of Kirin look like the prototype it really is.

Previously, Kirin was very much screen based – if you wanted to call out of Javascript to native you needed to find the currentScreenProxy which was left in a well known, but shared place.

var kirin = require("kirin");

exports.updateUi = function () {
    kirin.currentScreenProxy.updateUiWithData_(object);
}

Having to require("kirin") all over the place made testing difficult and caused problems with lifecycles which were akin to race conditions.

Now, the proxy for the native object is handed to the module at onLoad, which should happen at viewDidLoad: or onCreate() depending on what platform you’re on.

var theScreen;

exports.onLoad = function (ui) {
    theScreen = ui;
};

exports.updateUi = function () {
    theScreen.updateUiWithData_(object);
};

This should simplify mental models – you no longer need think in terms of “a proxy for the native object”, just “the object is passed to you”.

On the native side, calling Javascript was equally messy:

[KIRIN fireEventIntoJS:@"native2jsScreenProxy.onButtonClick()"];

This meant another object in global state, native2jsScreenProxy, and writing literal javascript code in app code, right in the middle of your native code.

It worked to prove a concept, but was never going to be something you’d want to live with.

Now we have a series of KirinHelper objects that manage a tight one-to-one relationship between a native object and a Javascript module.

These helpers manage the under-the-hood configuration needed to marshall the Javascript to Native communication, help manage the lifecycle of the Javascript modules, and are now the only way to call javascript modules and callbacks.

- (void) viewDidLoad {
    [super viewDidLoad];
    self.kirinHelper = [KIRIN bindScreen:self toModule:@"MyScreen"];
    [self.kirinHelper onLoad];
}

- (IBAction) onButtonClick: (UIButton*) button {
    [self.kirinHelper jsMethod: @"onButtonClick"];
}

Apart from elimiating the unsafe global state, it also gets rid of the awkward language of proxies and screens. This means that we can now use the same programming model of kirinHelper and injection for screens, custom components, platform services and Android Fragments.

The downside of this change is that we have had to break backwards compatability. Without compatible versions on other platforms, Kirin with Fragments is a cross-platform solution for a single platform. Android, then WP7, therefore, are a priority.

GWT

My colleague Mr. Hoskins is set to start this work very soon. This work is to make it possible to write as much (hopefully, all) of the shared code in your app in Java. Initially, this will be compiling down to Javascript to run in a browser for Android, but eventually, this will be running on Dalvik. I know he’s studying PlayN carefully.

This will be an optional component, so if you’d rather stick with Javascript you should be able to leave this alone.


Finally, we have a bunch of ideas for plugins, their implementations and their implications that we are quite excited by. For example:

  • re-using the work of node-browserify.
  • re-using PhoneGap plugins, particularly ones that didn’t use a WebView.
  • simplifying programming with services that need another screen.

That’s what’s happening to Kirin. I’m very excited by it. I hope to have more news… soon.

On possible iPhone NFC implementations

I was sitting in another workshop yesterday, brainstorming and plotting a new product, when someone said something that always surprises me:

“It’ll be so much better once we get the iPhone 5: we’ll have NFC”.

I will forgo telling what I thought of the tone or structure of the statement, but it started a train of thought that ends in me concluding:

  • iOS will not support NFC without a sustantial re-work/refactor/re-architecture of the entire OS.
  • Without such re-work of the whole OS, NFC will only be exposed to clients of private APIs, i.e. Apple supplied apps.

So here’s my working:

For the speaker who wanted to use NFC on their iPhone, it is an input method. A way of getting data to the app they were brainstorming.

Initially, at least, many NFCs transactions will ape those we already see using QR codes – passive chips transmitting a small piece of data, e.g. a URL. Given data transfer speeds, this will open up the technology currently occupied by RFID chips e.g. stock control as well as the more proximity intensive uses of QR codes, e.g. train time tables.

However, there are also a large space of possibility space for apps to explore using NFCs full potential: streaming of large quantities of data and two way communication. I cannot guess how app developers are going to start using this successfully once NFC transmitter and scanning devices hits critical mass in the mainstream. Turning your phone into a payment device, a identity token, or set of keys surely aren’t the most exciting things we’ll be doing with NFC?

And this is where I start thinking about basic things like addressing. Should I find and identify something as an NFC tag and I don’t know what app, if any, consumes it: what should my iPhone do?

I hope the responsibility of deciding which app consumes the tag does not rely on the user, as directed by some visual clue left by the makers of the app. Here lies the possibility of the world littered with tags left by the various checkin services, much in the same way the web was littered with a billion bookmark sharing servives. Think: “Scan me with Facebook Places”, meaning wake your phone up, launch the Facebook Places app, then scan it.

If I haven’t already launched exactly the right app, will the browser be the app that catches the tag, and implicitly consume it like any other browser URL. Most of the time, that’d imply a network call. I guess the subways of the world don’t need NFC innovation.

I say, most of the time: I understand custom URL schemes will get you some of the way, but when the app and the tag aren’t produced by the same entity, then what?

Let’s go to a simple example currently implemented with QR codes: train time tables. Let’s make it a little challenging, by putting it underground. Not out of the bounds of possibility for trains. The train timetable is available, up-to-date including bus replacement services, engineering work, and snow delays. Just scan your phone. Given that it is likely to be a public body producing the data and tag, is there going to be a single official app that consumes and displays that information, or will multiple unofficial apps, some of the thousand flowers that bloom from data.gov or other open data movements, all built with slightly different usages, and each of them competing ultimately on user experience.

i.e. if there are more than one app capable of handling the custom scheme of the URL, how is the phone going to chose which app to launch?

It is this inability to offer a choice of app to handle the same data in different ways (the custom URL handler is but an ugly implementation detail) that is the crux of my thesis that the underpinnings of iOS is going to require substantial modification to make NFC non-sucky.

Reading back on this, I could see an Apple implementation falling back on a single choice have-it or not. It be significantly less magical that NFC promises to be, and a worse user experience than Apple users would like, but it would be a fair attempt to coelesce a de-facto standard from the much more functional NFC standard, in favour of a flawed implementation.

Open Sourcing Kirin

This week has been a really exciting for me, for multiple reasons:

  • We open sourced some tech I’ve been involved with at work, called Kirin. I have a feeling it’ll generate quite a lot of interest.
  • Over the Air 2011 happened, at Bletchley Park. I presented Kirin and also an Ignite talk. Both seemed well received.
  • I presented at DroidCon UK on Friday, also announcing Kirin.
  • I got a tablet at the courtesy of Samsung Europe from the good folks at Google’s Android Developer Labs.

Kirin started off as an approach to solve the problem of writing the Glastonbury 2011 app for multiple platforms – specifically for iOS, Android and Symbian/Qt.

We looked at a number of other ways of doing things, but found that none of the current options fit our problem.

As we thought about it more, it became clear that this was something that was not specific to just our current app – it could be a viable alternative cross platform toolkit.

Kirin starts with the simple premise: Javascript logic, native UI.

  • Write as much as possible portably – your business logic, and non-UI components – in a language that is in every browser, and so every modern smartphone.
  • For each platform you’re targetting, write a native UI that is appropriate for the platform, and that the users will expect.
  • Make it as easy as possible for the Javascript and Native pieces to talk to each other.

Today, following on from the success of the Glastonbury 2011 app (featured in three app stores, and winning awards), Kirin has moved from an approach to a framework. And we’ve decided to put it onto Github, under an Apache licence.

Right now, it’s a little opaque how start using Kirin for your own development. This I expect/need this to change. The most excellent Matt Gaunt has pledged to plug away at this, as well as build some demo apps; I will be doing the same.

You can watch how all this unfolds at Kirin’s home at Github.

Presenting Kirin has been a joy – the highlight of the month was the lovely reaction from the good folks at Droidcon, on hearing we open sourced Kirin.

Lots of questions and great feedback from so many people, including a number of very interesting offers…

#bcb6 - The Technology of Revolutions

I spent a lovely two days this weekend at Barcamp Brighton.

One of the New Year's Resolutions I made in March was to do more public speaking - so this year has been the Year of the Flappy Mouth.

This weekend I had a second go at a subject I've been watching for a long, long time. I particularly focused on the technology in use in grassroots mass participation political action - revolutions and protests.

I took a leaf of the Beyond Bullet Points, emulating the amazing slide decks that Bryan and Stephanie Reiger routinely produce: coherent, logical discussion presented beautifully.

I don't think I've hit those high notes yet. Despite a few rough areas, I was satisfied with what I did, and I was really pleased with the number of discussions it provoked throughout the rest of the day.

A number (well two) people have asked me to publish the slides. I don't know if I'm in a position to do that in their current form, but I have links to the projects I highlighted:

Old School / Ancient history

Ushahidi

Counter measures

Counter-counter-measures


I expect I'll present this again - it's not very technical and very topical, not covered very much all in one place, and it's an area still in flux.

Offline QR Codes

Today I are mostly be thinking about offline QR codes.

All the barcodes I can think of are physical identifiers or pointers to a remote, digital resource. I'm thinking of ISBN numbers, URLs, product ids etc. To mean more to the user than a serious of arbitrary characters, in each case, the device needs to open a network connection and download something - some product details, or an app.

One of the recurring themes in my mobile interest is offline mode. Having an unreliable network connection is, or should be, considered normal - so what can we do during those times when a network connection is not there.

So here's my design constraints:

  1. You may have a special app installed.
  2. The app may be extended with data or code not available at the time of writing the app.
  3. The network may not be used to obtain code or data. The data/code should be obtained from a QR code or NFC tag.
  4. There is no restriction where QR codes & NFC tags can be placed.
  5. The app and accompanying tags would have enough utility to spread, and have a chance of being Big in Japan or elsewhere (this is to exclude the science fair projects, or the uses which are just so convoluted that no one will ever use them).
  6. Bonus: the app should be flexible enough to allow unexpected augmentation that surprises the developer.

So, them's the rules. What can you do with them?

The degenerate answer is of course, vCards for contact data. Can I imagine QR codes mediated cottaging - up to a point, yes. Do I think it would catch on? Hmm, no.

What about speciailist apps, which solved a very specific problem, but across any number of tag producers? QR codes can hold up to about 4k in alphanumeric characters, what can you do with that?

  • Timetables - e.g. a replacement for the SMS "Next bus" service you can text from any bus-stop.
  • Opening times - e.g. across the Christmas period there are many variations of opening times.
  • Cinema listings
  • Collectibles/Coupons. A coupon that is redeemed is against the spirit, if not the letter of the above constraints.
  • Menus on the outside of takeaways/restaurants

Here's where it gets interesting for me, just from a nerdgasm p.o.v.: executable code encoded in a barcode. Javascript would be the obvious choice. You can do a surprising amount for 4K.

  • A collectible mini-game? e.g. a bonus game within a larger IRL/big game.
  • A conversion tool that is not trivially reproduced by a repetitive formula and some constants. e.g. that call charge card to call abroad may supply a function which could tell you how much a particular call will cost, given the time as well as the duration and country you expect to dial.

I am running out of ideas now, and I don't think I have come up with anything really compelling, I don't think. Yet.

Of course, any of this that can be applied to QR codes can be applied to NFC too.

Wear Sunscreen: Ten Things To Do To Make Your Android Development Easier

I’ve been working with Android for the past 18 months or so. The most successful app I’ve written is an app to download a newspaper each night, ready for offline viewing during the day. That’s the Guardian Anywhere.

Since I’m now a seasoned professional and all, I thought I’d pass along some of the things I thought may be transferable to other projects. I didn’t want to aim this at newbies, but fair warning: WARNING: this is not advanced. Not in a Higher Order Haskell sense anyway.

While writing this post, it occurred to me that

  • I don’t really know what to call each item
  • some are small features, some in the loosest sense “patterns”, and some just friendly advice.
  • some of them are really small, some completely obvious; others, particularly ones to do with databases, may not be suitable to all projects.

This has lead to the format of a commencement speech, as suggested by Mary Smeich popularised by Baz Luhrman in Everybody’s Free (To Wear Sunscreen). Listen to the last link – it’s a fun couple of minutes if you haven’t heard it recently.

I’ll try and group them in some coherent order, though I expect it’ll drop out as the easiest to implement first.

Logging

1. Keep your logging tag in a constants file

This is an easy tip to start with: each project I start, I start a constants class. I usually go with Josh Bloch’s idea of a constant class (i.e. non-instantiable, non-extendable class) called C.

public final class C {
    private C() {
        // No instantiating
    }
    public static final String TAG = "MyApp";
}

So all logging statements are now of the form:

Log.i(C.TAG, "Something happened!");

Now you are using a single tag identifier, in every project, you can set up an Eclipse template for control-space:

${:import(android.util.Log)}Log.${i}(C.TAG, ${word_selection});

You probably shouldn’t put all your constants into the C class, though I have found having it as a single place to put menu item ids makes it very easy to ensure that there are no collisions.

2. Use logcat from the command line

Perhaps I’m a little too wedded to the command line. However, I found early on that having logcat in a window completely separate from Eclipse really helpful.

From within the Android SDK directory, in your Terminal or cmd.exe, you can invoke a filtered view of the log:

% ./tools/adb logcat -v time MyApp:* *:E

This will show timestamped loglines from MyApp (MyApp:*), and all errors, whatever their source (*:E). You can add additional filters if you’re using two or apps that work together just by adding tag:level pairs.

3. Enable users to capture logs and send them to you

If you plan on releasing early, or having any kind of beta testing period, or assume the worst and actually ship a code path you haven’t been able to test, it is extremely useful for the users to be able to send you application logs.

The best way I found to do this is to use the Android Log Collector, an open source third-party app which you can direct the user to download and then invoke programmatically with an intent.

I put this is in a settings pages, where the average user isn’t likely to find it unless directed. This is much, much easier than asking them over email to send logs, with instructions on how to do that.

You can give the log-collector the same filters that logcat uses on the command line, so the user isn’t sending an enormous file.

The same intent gives you ample scope to add extra text containing the app’s version information, its environment, and even some performance characteristics. Below is the header I get before the log itself.

Application:     
App Version: 2.1.1 New: Search for tags online.
App Version Code: 2110
Last download took 06m 02s.
There were 5 new images and was 166KB in total.
At last count, there were 1870 files on the SD card, occupying 57.91MB

Device:     
Model: HTC Desire 
Brand: htc_wwe
Release: 2.2
SDK: 8
Product: htc_bravo
Display: FRF91
Tags: release-keys
Locale: it_GB

Essentially, anything I can find out which:

  • I’ve found myself asking the user for before, to track down a problem
  • is non-private, i.e. not intrusive on the users privacy
  • I can find programmatically

is a candidate to be put in the header of this log email.

Databases

If you’re using an SQLite database in your app, then these may already be self-evident.

4. Add a debug option to copy the database onto the SDCard

Recently while debugging a particularly SQL heavy feature, I really wanted some real usage data. I couldn’t really get that from apps installed on emulators, because I wasn’t using those instances for long enough, and I didn’t want to root my everyday device which did have enough usage on it. The answer I came up with was to have an option menu on the front screen of my app which was only switch on when attached to a debugger. i.e.

C.DEBUG = Debug.isDebuggerConnected();

The copying is fairly simple, though the file locations needed a little bit of research:

try {
    File dataDir = Environment.getDataDirectory();
    File sdCard = Environment.getExternalStorageDirectory();
    File destFile = new File(sdCard, "GuardianAnywhere.db");
    File dbFile = new File(dataDir, "data/" + context.getPackageName() +  "/databases/" + DATABASE_NAME);
    Log.i(C.TAG, MessageFormat.format("Copying {0} to {1}", dbFile.getAbsolutePath(), destFile.getAbsoluteFile()));
    // use a project specific IOUtils.
    IOUtils.copy(new FileInputStream(dbFile), new FileOutputStream(destFile)); 
    // takes care of closing both streams.
} catch (IOException e) {
    Log.e(C.tag, "Error copying the database", e);
}

Once on the SD card, it’s a job for adb:

% ./tools/adb -d pull /mnt/sdcard/GuardianAnywhere.db ~/tmp/GuardianAnywhere.db     
% sqlite3 ~/tmp/GuardianAnywhere.db

Once you have an sql console, I tend towards a text file and console pattern, gradually refining my statements with minimal typing.

5. Don’t be afraid to index your database

I’m not going to go into the specifics of optimising the database for anything in particular – I’m still not convinced I can speak convincingly about the subject, I’m fairly sure I’m not completely there yet with the Guardian app, and most of what I can say will be application specific. So, what I’m left with is the equivalent of a Wear Sunscreen.

A caveat to indexing your database is to switch off the indices if you’re doing bulk inserts.

6. Allow the users to send you their database

This is combining (3) and (4) above. I haven’t tried this, but I’ve wondered how useful it may be. I think you can cajole the android log-collector app to attach a file to the email it will send to you.

Depending on your app, this could be quite privacy invasive.

Depending on your logging, this may have little additional value that can be had elsewhere.

UI

7. Context Menus are short cuts to option menus in detail screens

The classic arrangement of context and option menus is that of a items in a list: in the list view, the option menu is for things to do with the whole list. The long-tap should give you a list of things to do with a single item in that list. Similarly, you should be able to tap on the item, and be taken to an item specific activity, where you should be able to do all that you could from the context menu, but in the option menu.

The solution: use menu helpers. These are POJOs that can be instantiated by both list and item activities, but collect the functionality into a single place. This is the method signature of a class called ArticleMenuHelper.

void onCreateArticleMenu(Menu menu, Article article);
void onPrepareArticleMenu(Menu menu, Article article);
boolean onMenuItemSelected(MenuItem item, Article article);

8. Make sure list views theme okay

This took me a little while to track down. For applications and activities that have a light theme, or a dialog theme, you get this annoying background colour change between when a ListView is moving and when not. This seems to be fixed with:

getListView().setCacheColorHint(0);

9. Preference pages: add a version number taken from the manifest file

String version;
int versionCode;
try {
    PackageInfo packageInfo = getPackageManager().getPackageInfo(getApplication().getPackageName(), 0);
    versionCode = packageInfo.versionCode;
    version = packageInfo.versionName;
} catch (NameNotFoundException e) {
    version = "unknown";
    versionCode = 999;
}
findPreference("app_version").setSummary(getString(R.string.prefs_summary_app_version, version, versionCode));

You may also want to put in database version info too, though I think this is a little too much. If you’re tagging your builds properly, you should be able to derive this easily.

This would also be a place to put stats about the application’s demands it puts on the system, and how well it’s performing. Just by providing the user information about how many files the app has actually got stashed on the SD card seemed to reduce the number of feature requests for a “clear cache/old stories” feature.

10. Test in multiple locales

This is prompted by a recent fix of a bug which baffled me for a little while. It turned out that a very small number of users were not able to see dates that should’ve been parsed. In a later release, I received an email from a particularly supportive user stating that “Sorry.. but your app is simply BROKEN, at least on my Milestone 2.1.” I’d not been able to reproduce the bug, but looking through the logs, I realised he was German. The logs gave me a stack trace, but no real cause.

Sure enough, once I switched the locale of my device to a non-English locale – Italian was available – I was able to reproduce the bug. The cause was I was using a default constructor for SimpleDateFormat, when I should’ve been using a UK Locale-ised one:

new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z", Locale.UK);

This completely fixed the problem. I added the Locale to the Application Logs header above as part of the fix.

Conclusion

As you can see, some of them are little more than a war-story, but most, if not all of the above have earned their place in my android dev tool chest.

If you have any advice/patterns/featurettes you’ve come to depend upon, I’d really like to hear them.

Fonts. Fonts. Android. Fonts.

Quick reminder on how to use extra fonts.

I really like the Droid series of fonts, though I have recently found myself thinking that Droid Sans doesn't quite look right for black-on-white text

Here's a very simple, and likely incomplete guide to acquiring and using fonts.

Sourcing your new font is likely to be tricky if you want something like Helvetica or Courier, but there are plenty of freely-licensed or Creative Commons fonts available. I found Typekit a good starting place, which lead me to the free font foundry The League of Movable Type and Red Hat.

According to this commonsware.com, OTF fonts are not supported on the 'droid. So if you find OTF files, then you can convert them with the Online Font Converter, which converts fonts, online. We need TTF fonts in this case. (apparently the OTF is the more modern of the two, but this is way beyond my area of expertise).

Once you have your new, free TTF file, you can put it in the assets directory of your app. 

I haven't found a way of setting the fonts directly from the XML for standard components, however, you can load the Typeface with: 

     Typeface sTypeFace = Typeface.createFromAsset(ctx.getAssets(), TTF_FILENAME);
  TextView tv = ....;
  tv.setTypeface(sTypeface);

Not much to this it seems, but I think there's more to find out with styling from a layout.xml file

I've attached a screen shot of an app I'm working on with the changed fonts. Currently, only the button bar at the bottom has Droid-Sans on it. 

.
Music-fonts-blog-post-smaller

Two taxonomies and a manual of sabotage

No original thought, no real additions to the global corpus of knowledge, just three lists I think of every so often, and need to look up again.

The first is from Jorge Luis Borges' book within a book. The outer book is The Analytical Language of John Wilkins, the inner book is Celestial Emporium of Benevolent Knowledge.


These ambiguities, redundances, and deficiences recall those attributed by Dr. Franz Kuhn to a certain Chinese encyclopedia entitled Celestial Emporium of Benevolent Knowledge. On those remote pages it is written that animals are divided into
(a) those that belong to the emperor;
(b) embalmed ones;
(c) those that are trained;
(d) suckling pigs;
(e) mermaids;
(f) fabulous ones;
(g) stray dogs;
(h) those that are included in this classification;
(i) those that tremble as if they were mad;
(j) innumerable ones;
(k) those drawn with a very fine camel's-hair brush;
(l) etcetera;
(m) those that have just broken the flower vase;
(n) those that at a distance resemble flies.

The only disappointment for this list is that (h) is not "those that are not included in this classification". Apparently Dr. Kuhn was a real person, though Borges was fond of mixing fact with his own fictions. Splendid stuff.

The next is the Five Orders of Ignorance from Philip Armour in ACM 2000:

  • 0th Order Ignorance (0OI) — Lack of Ignorance I have Zeroth Order Ignorance (0OI) when I know something and can demonstrate my lack of ignorance in some tangible form, such as by building a system that satisfies the user.
  • 1st Order Ignorance (1OI) — Lack of Knowledge I have First Order Ignorance (1OI) when I don’t know something and I can readily identify that fact.
  • 2nd Order Ignorance (2OI) — Lack of Awareness I have Second Order Ignorance (2OI) when I don’t know that I don’t know something. That is to say, not only am I ignorant of something (I have 1OI), I am unaware of that fact.
  • 3rd Order Ignorance (3OI) — Lack of Process I have Third Order Ignorance (3OI) when I don’t know of a suitably efficient way to find out that I don’t know that I don’t know something. So I am unable to resolve my 2OI.

The Fourth Order of Ignorance is:

  • 4th Order Ignorance (4OI) — Meta Ignorance. I have 4OI when I don’t know about the Five Orders of Ignorance. I no longer have this kind of ignorance, and now, neither, dear reader, do you.

Cute.

The various taxonomies of the unknown are very worth looking at too.

Finally, one currently making the rounds, from a 1944 CIA manual on speech quoted at Enterprise 2.0, and linked to by Boing Boing:

  1. Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions.
  2. Make “speeches.” Talk as frequently as possible and at great length. Illustrate your “points” by long anecdotes and accounts of per­sonal experiences. Never hesitate to make a few appropriate “patriotic” comments.
  3. When possible, refer all matters to committees, for “further study and considera­tion.” Attempt to make the committees as large as possible — never less than five.
  4. Bring up irrelevant issues as frequently as possible.
  5. Haggle over precise wordings of com­munications, minutes, resolutions.
  6. Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.
  7. Advocate “caution.” Be “reasonable” and urge your fellow-conferees to be “reason­able” and avoid haste which might result in embarrassments or difficulties later on.
  8. Be worried about the propriety of any decision — raise the question of whether such action as is contemplated lies within the juris­diction of the group or whether it might conflict with the policy of some higher echelon.

--
J