Slashdot Mirror
Eric Schmidt Doesn't Think Android Is Fragmented
adeelarshad82 writes "Eric Schmidt took issue with the idea that the Android mobile operating system is fragmented, arguing that it's a differentiation between devices rather than a fragmentation. The difference, as he explains it, is that differentiation means manufacturers have a choice, they're going to compete on their view of innovation, and try to convince consumers that their innovation is better than somebody elses whereas fragmentation is quite the opposite. Not surprisingly, some company analysts beg to differ, pointing out the ever increasing incompatibilities between OS and apps across different Android devices and other problems with Android."
Most apps work fine across all common Android versions; the only ones that don't are those that require functionality that just wasn't available on earlier devices. Most of the so-called "fragmentation" is things like manufacturer-specific apps and launchers. Those do exactly what Google says they do: they allow manufacturers to differentiate themselves from one another. That may not be a good thing (I prefer "pure" Android), but it isn't a problem.
I think a lot of the complaints from developers about fragmentation is complaints from iOS developers, who are used to an unusually rigid level of constraints across devices and have developed bad coding practices (like hard-coding coordinates and layouts etc.) because of it.
The fact though is that Google provides the tools for developers to handle the variations in screen size and such and in practice developers don't seem to be having too much trouble with the fragmentation issue.
I'm just finishing up my first Android app. It's a simple app, yet several times I've already needed to use reflection to dig around in undocumented APIs or roll my own version of a class included in the framework because of differences between the API versions. I have also found that it is difficult to add functionality to framework classes because Google makes many of the methods either private or final.
The target demographic for smartphones is geekier than the average public. Most geeks have smartphones, for example. Teenagers and young adults regularly defy the traditional concept of "too geeky" or requiring too much effort for the "average" person, and these same are also among the prime candidates for smart phones.
Nonetheless, "fragmentation" is a marketing term being bandied about by Apple apologists. It's an excuse to justify a technology monoculture that Apple has established in some corners of the market. Technology monoculture has invariably led to technology stagnation.
Rather than "fragmentation" being a bad thing, what's actually going on is "innovation," and that's a good thing. People didn't talk about desktop fragmentation in the PC era, people don't talk about console fragmentation when you need specialized controllers to interact with many of today's games.
This is survival of the fittest. My wife is a complete non-geek. She traded out her iPhone for Android and is eager to ditch her iPad. The sole reason being that she wants to consume content which requires Flash. She's not interested in assertions that her life would be better if only websites would ditch Flash, she's interested that her technology can't do the task she wants it to.
Technology monoculture is the real problem here. iOS suffers from it, while Android doesn't. Android should wear this term with a badge of pride; they are currently steadfastly half way between steps 2 and 3 (out of 4) in Gandhi's famous quote about winning. They were ignored (Android 1.x era), they were laughed at ("fragmentation"), now they're being fought (Apple v. Samsung for example). Only one more step to go.
Slay a dragon... over lunch!
I'm just finishing up my first Android app. It's a simple app, yet several times I've already needed to use reflection to dig around in undocumented APIs or roll my own version of a class included in the framework because of differences between the API versions. I have also found that it is difficult to add functionality to framework classes because Google makes many of the methods either private or final.
Good luck with that app. Yes, unfortunately many Java developers think that good encapsulation means making a lot of stuff private or final. Actually what it often means is that the code is not fit for re-use, you end up re-writing code to do the same stuff that in a more open way and use that. IMHO if you are a Java developer that automatically defaults to private and final methods, forces the use of singletons or factories instead of trying to make POJO JavaBeans which can then be used as singletons (or as ordinary objects, as the need arises) then you ought to consider yourself an orthodox developer that is probably not like by anyone forced to re-use your code.
Part of the problem is the attempt of Java library writers to try and protect the user from themselves. I used to do this but after using so many other libraries over the years I now think this is misguided. Now I try and make POJOs and POJO services whereever I can and make sure I properly Javadoc what needs to happen and also check the preconditions and arguments of all method calls. IMHO I find that in later stages of a project I have access to all sorts of information I need, rather than having to continually go back and publish formerly private methods due to inflexible and closed interfaces. A little bit of encapsulation is good (avoid non-final public members for sure) but that does not mean encapsulating yourself into a straightjacket is good either
Sorry for getting a bit off-topic there, but I hear your pain with the currently 'orthodox' way that Google close their framework off. If there are any Java devs reading out there - keep it POJO if you can and unless you have an extremely good reason for using a private method you should make it public (which also helps unit testing too). And ffs write *meaningful* Javadoc about what can and can't cause usage of the class to fail (eg. preconditions, what argument values are invalid etc).