Fragmentation is a Bad Excuse

Ah, fragmentation. The marketing term that has even blinded developers. The word that lets software engineers make excuses for writing bad software. But hey, don’t let me stop you from complaining. I’ve been developing for Android long enough to know that it’s not an easy thing to make apps for devices like the Galaxy Nexus while still supporting low-end devices like the Samsung Replenish. Yeah, two completely different devices. I know it’s not easy. But you won’t find me saying Android sucks because of it. In fact, you’ll find me praising it for that exact reason.

You can go ahead and brag that iOS development is easy. Yeah, I’m listening. But before you continue, I want to ask you something really, really important: are you seriously okay with having one device with one operating system powered by one software market run by one company? I’m not talking on a “control” level, I’m talking on an innovation and choice-of-use level. If so, you can go ahead and do what you want. But if you believe in the growth of technology and the power of scalability – this is for you.

Android (Google’s version and the open source one) fits on multiple kinds of screens and resolutions and handles numerous kinds of hardware that the Android team doesn’t control. On top of that, they’ve built a framework that scales applications that they also don’t control. Take a second to understand this. Do you realize how amazing this is? Do you, as a developer, understand that this is one of the toughest level of scalable software you’re going to encounter? And then you’re going to complain about an app on top of a VM and a framework that gives you tools to make things scale? Seriously?

Programming is a challenge. Scalable programming is that much harder. Android involves the latter. The fact that there are different screen sizes, resolution, and underlying hardware is bad enough, but the fact that OEMs and carriers take their sweet time to upgrade to the latest OS makes things even more difficult. That being said, majority of applications won’t need more than what the framework tools in FroYo (2.2) gives us, so that’s a really great thing and if you do, there are backwards compatibility libraries to make sure you can use them even then.

You know what else is great? Google’s made it quite easy to make your applications scale properly. Yeah, it’s all in the framework – you don’t need to build something to do it. Things like RelativeLayout and weighted layouts make a developer’s life really easy when it comes to handling mulitple kinds of devices. I’ve made incredibly complex layouts that scale onto any screen and resolution quite easily – yes, even between the Galaxy Nexus and the Replenish. It’s completely possible and it doesn’t take that much more effort. It just means you, as a developer, need to properly write your code.

You can keep saying that fragmentation is a problem, but I’m about to tell you the problem with iOS: it’s tailored. It’s tailored to the point where if Apple ever increases the size of their device (or, as we saw with the iPad – increases the resolution), too many applications won’t work properly. That means that the app store that Apple themselves controls will fall into shambles because they never prepared developers for such a change. Or, on the other hand, they’ll never change the screen size of their devices, which is even worse if you ask me.

Scalable beats tailored 100% of the time, so don’t complain if you’re required to do it. Once you learn how to do it on your specific platform, it’ll be a breeze to do it from then on. It’s just a matter of not being lazy and taking that first step.

Be a software engineer that scales, because that’s what software engineers do. Don’t be afraid of the most important task you have as a developer.

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 50 bytes) in /home/content/99/6062999/html/blog/wp-includes/cache.php on line 503