I’ve been developing iOS apps since the end of 2010, so have only ever seen the world of Android from a distance. Where I’m from, you hear a lot of talk about the problem of fragmentation on Android. Whereas the adoption stats for new versions of iOS are pretty impressive (apparently iOS7 hit 33% iOS market share in just 24 hours, and 58% after one week) the situation on Android looks very different, with the second most popular Android version remaining Gingerbread, released in 2010.

With my iOS hat on, when PrayerMate launched on Android earlier this year, I assumed it would be far too much hassle for one independent developer working in his spare time to take on this fragmentation issue, so I decided to support only Honeycomb upwards – a major OS update which introduced some significant new changes to the core Android UI.

But what they don’t tell you over in iOS developer world is that the Android ecosystem provides some pretty impressive tools to make supporting older Android versions really easy. Let me give you a quick overview of just three reasons why adding support for older phones isn’t nearly as hard as you might imagine:

1. Compatibility-aware compiler

When you set up your Android project (I use Eclipse) you specify the minimum version your app supports. Out of the box, the compiler knows exactly which API level each feature was introduced at, and will throw a compiler error if you try to use functions that are too modern for the versions you claim to support. If you use conditional statements to alter behaviour by Android version, then you can use attributes in your code to say what API level a given function is designed to run against, to disable these compiler errors on just those bits of code. It also warns about deprecated APIs so that you can use more modern alternatives where appropriate.

This makes the situation so much easier than the native state-of-affairs on iOS. It wouldn’t surprise me if there was some way to figure out how to make XCode throw such compatibility errors, but out of the box you get no warning whatsoever if you use functions introduced in an iOS version later than the minimum one you hope to support, and the only way to discover this is through thorough testing and waiting for the crashes to happen (which needless to say is not very scalable!)

2. Compatibility support libraries

Another seriously impressive feature of the Android SDK is the compatibility support libraries. In many situations, where a new API has been introduced, the SDK then goes and adds an alternative implementation that conforms to the same method signatures but which ports the new functionality back so that it also works on older OS versions. This avoids the need to have lots and lots of conditional branches running separate codepaths on separate Android versions, and instead means you can just write one lot of code that works everywhere.

3. ActionBarSherlock

Ok, so this one isn’t native to the Android SDK (although a very similar library is) but there’s a great open source project out there called ActionBarSherlock which lets you add the “action bar” UI paradigm introduced in Honeycomb even when running on older Android versions. It requires a minimal amount of setup, and works almost identically to the real action bar. So, again, rather than having to invent two separate user interfaces depending on the Android version, you can have the same functionality running everywhere.

Conclusion

In conclusion, the Android fragmentation problem doesn’t seem nearly so scary to me as it once did. I managed to get PrayerMate to support Android versions all the way back to Froyo (v2.2) in a single (pretty relaxed) weekend, and because of support from the compiler I can be pretty confident of not having missed anything.

Want to make a computer programmer groan? Just ask them to explain “unicode” to you and watch what happens, as all of the joy drains out of their face in an instant.

It turns out that an ancient story from one of the very earliest chapters of the Old Testament still casts a shadow over software development in the 21st Century. Which story? The account of the Tower of Babel and God’s subsequent judgement on the world – a judgement which still makes itself felt these many thousands of years later.

In the days of Noah, God recognised that the intentions of man’s heart was “only evil all the time”, and so he made a fresh start of the world, beginning again with just Noah and his family. Yet the human capacity for evil was undiminished, and it’s not long before we see the human race trying to exert their independence from God: “Come, let us build ourselves a city and a tower with its top in the heavens, and let us make a name for ourselves, lest we be dispersed over the face of the whole earth.”

In one of those verses that proves what a sense of humour God has, we read that whilst they were busy trying to build the tallest tower imaginable, reaching to the very heavens, God still found it necessary to “come down” to get a closer look at the city and the tower, which the children of man had built.

“And the Lord said, ‘Behold, they are one people, and they have all one language, and this is only the beginning of what they will do. And nothing that they propose to do will now be impossible for them.'”

It was a period of unprecedented harmony for the human race, but how did they choose to use that spirit of co-operation? To rebel against God and try to throw off his shackles, making a name for themselves. Even then, God loved us too much to leave us to this rebellion, and so he proposed a judgement fitting the crime:

“‘Come, let us go down and there confuse their language, so that they may not understand one another’s speech.’ So the Lord dispersed them from there over the face of all the earth, and they left off building the city. Therefore its name was called Babel, because there the Lord confused the language of all the earth.”

Whilst their great intention was to prevent themselves being dispersed across the face of the earth, God did the very thing that they were afraid of and caused them to divide and spread out across the earth. He muddled their languages so that the unity they had previously enjoyed was destroyed, and in its place there was misunderstanding and gobbledegook.

And that, my friends, is why software developers today still have problems making their programs handle foreign characters properly. It’s not simply that computers can’t agree on what language to speak – in many ways, English is the common tongue of most software. It’s that even when there IS agreement on the language, computers can’t even decide quite how to represent that language. As Joel on Software explains in his excellent little introduction to Unicode:

“In Unicode, a letter maps to something called a code point which is still just a theoretical concept. How that code point is represented in memory or on disk is a whole nuther story.”

The humble apostrophe causes no end of problems in even otherwise very straightforward English documents, if you use the curly kind rather than the straight line variety, since depending on the character encoding you use to save your document its codepoint could be presented in all manner of different ways: ISO-8859-1, UTF-8, UTF-16, big-endian, little-endian, blah blah blah. When you start getting in to languages with lots of accented characters like French, or even whole different alphabets such as Chinese, then it starts to get completely unmanageable unless you understand what you’re doing. And even when you understand what you’re doing, chances are you’re having to interact with libraries and services which DON’T understand what they’re doing, or which decide to handle things in an ever so slightly different manner.

So God’s curse on the sinful intentions of our hearts is still making itself felt even today. It can add all sorts of overhead when trying to get software based on different platforms to talk to each other. We’ve come a long long way from where we were a few years ago, but even so it can still cause much banging-ones-head-against-a-wall.

And so we cry, “Come, Lord Jesus!”