Lots of people have been banging on about Android fragmentation and that it is all going to end up like J2ME and we are all going to explode big splurge. I am pretty relaxed about this as fragmentation is just a fact of life in mobile – because we are dealing with consumer electronics after all – and to be honest it is just the natural state of things, look at all the browsers hacks people take for granted.
That said in creating the “VIP Call” app for Android I came across a real live fragmentation example and here it is:
“VIP Call” depends on being able to access the Contacts on the phone via an intent like so:
Intent intent = new Intent(Intent.ACTION_PICK, People.CONTENT_URI);
startActivityForResult(intent, PICK_CONTACT);
and process the returned contact like so:
Uri contactData = data.getData();
Cursor c = activity.managedQuery(contactData, null, null, null, null);
if (c.moveToFirst()) {
String name = c.getString(c.getColumnIndexOrThrow(People.NAME));
String number = c.getString(c.getColumnIndex(”primary_phone”));
return new Vip(name,number);
} else {
return null;
}
This works fine in 1.5 and 1.6 but fails in > 2.0 – my Droid users were not happy.
Turns out the contacts API has been re-written pretty extensively for 2.x so that there is support for multiple accounts. What’s more it aint backwards compatible.
The solution – suggested by google – is to create a ContactsAccessor class that encapsulates the two different implementations. So the call to the Intent now looks like:
startActivityForResult(mContactAccessor.getPickContactIntent(), PICK_CONTACT_REQUEST);
I wont list the full solution here as Google have provided a full example solution in the android-business-card code.
I must say this bit of code in the solution gave me J2ME Vietnam-like flash backs:
/*
* Check the version of the SDK we are running on. Choose an
* implementation class designed for that version of the SDK.
*
* Unfortunately we have to use strings to represent the class
* names. If we used the conventional ContactAccessorSdk5.class.getName()
* syntax, we would get a ClassNotFoundException at runtime on pre-Eclair SDKs.
* Using the above syntax would force Dalvik to load the class and try to
* resolve references to all other classes it uses. Since the pre-Eclair
* does not have those classes, the loading of ContactAccessorSdk5 would fail.
*/
@SuppressWarnings(”deprecation”)
int sdkVersion = Integer.parseInt(Build.VERSION.SDK); // Cupcake style
if (sdkVersion < Build.VERSION_CODES.ECLAIR) {
className = “com.example.android.businesscard.ContactAccessorSdk3_4″;
} else {
className = “com.example.android.businesscard.ContactAccessorSdk5″;
}
Tis my own opinion that fragmentation in Android is going to be on a par with the fragmentation we find in the browser world rather than the J2ME experience. The major reason for this is that the Android OS is over the air upgradable – my G1 has already had about 3 upgrades – this was not possible in the J2ME giving us the long tail we know and love 
.
