Categories
Uncategorized

Yes, Android Has a Fragmentation Problem… but So Does BlackBerry!

I’ve been reading a lot lately about Android and its problem with fragmentation. There are many people weighting in with their opinions on whether or not it is a real problem. As a consumer, I’m not too concerned since I like having choice when selecting a new device: screen size, internal memory, speed, etc. However, as a developer I have to say that it is a real pain to deal with, and it is one of the reasons that I’m not too enthusiastic about EVER developing a native Android app.

But I’m not really interested in complaining about Android today. The reason for this post is because I am surprised that I’m reading so much about Android having a fragmentation problem but I rarely, if ever, hear about BlackBerry having a fragmentation problem. Android’s fragmentation is being blamed on the numerous device makers who are making their own decisions on how to put a phone together: screen size, internal memory, user interface and available system services. RIM however has managed to create fragmentation with their BlackBerry devices all on their own, and I had the pleasure of experiencing this first hand while creating Briscola (Check out the Paid or Free version).

Briscola, was created using the WebWorks platform, which is basically a way of creating an app using HTML5 technologies. One problem here is that the webbrowser in BlackBerry OS 5, 6, and now 7 (and updates inbetween those versions) are all very different and they don’t support the same features. So Javascript that runs in OS 7 isn’t guaranteed to work in 5 or 6. Now, it is perfectly understandable that new OS versions will introduce new features, so I won’t condemn RIM for doing that.

The biggest problem here was with the different screen sizes. Within a given year, there are several phones released with many different screen sizes. From portrait to landscape phones, to different resolutions for each of those configurations. This makes it very frustrating to develop an app that relies on specific positioning of certain user interface (UI) elements. So on one hand, you can try to design a UI that fits all screen sizes and looks mediocre on each, or try to design a seperate UI for each different screen size that looks good on each.

The other complaint that I have with WebWorks development (I’m not sure when this post changed from a rant on fragmentation to me airing grievances with WebWorks, but lets just go with it) is the fact that you cannot perform any offline storage unless a memory card is present in the expansion slot. There was a situation where I wanted to simply store a single bit of data to signify if the ‘No Ads’ in-app item was purchased, and the only option I had to store this data was to create a sqlite database to store it in. If there was no memory card, then I’d have to have the user log-in to App World every time they ran the app to check if they made the purchase (which is a horrible user experience). Needless to say I didn’t implement it this way and simply made a separate free and paid version of the app. The only other option that was given for storage was cookies, however they don’t persist after rebooting the phone so it was not a viable option either.

Back on the subject of Fragmentation, Android’s screen size issue is the same as BlackBerry. As a developer, you’re left to either create a mediocre UI that somehow fits in each screen (there are exceptions to this of course) or create a separate UI for all known screen sizes.

With all that said, I am very happy that there is still one environment that I can develop in and not worry about having to consider countless screen sizes: iOS. The iPhone app that I’m developing now has a single screen size. The app I am making fits the same way on the 3GS as it does on the 4 and the 4S. Even with the inclusion of the Retina Display, the screen’s coordinate system hasn’t changed (since everything has just doubled — that is easy math!), just the resolution of the images that I can show on screen (all thanks to the COCOS2D framework). The same is true for apps developed for iPad; you get the same screen layout for both iPad 1 and iPad 2, and the soon to be released iPad 3, regardless of the inclusion of a Retina Display.

Now, there are some rumors that have come out over the last year that said the last iPhone was supposed to have a larger screen and that the next one will as well. However, there are a bunch of smart people who are saying that it won’t happen. And I’m in the same camp as them, simply because it will be very difficult to convince everyone who has already developed an app to go back and re-write their apps to fit a larger screen. And using software in the OS to force the apps to fit a bigger screen will look so bad that I can’t see Apple even trying it.

The big question I’m left with from all of this is: What is BlackBerry’s excuse? The reason Android has a fragmentation problem is because each of the device manufacturers need to have a way to distinguish themselves from eachother. But RIM had complete control to eliminate or simply minimize the issue. Why have 4 different portrait screen dimensions; stick with one and just play with multiplying the resolution by a constant factor. That alone would make my life easier when I decide to hand-craft separate UIs.

Leave a Reply