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."
put's positive spin on a potentially negative product quality. Film at 11.
Totally shocked that the CEO of the company that licenses Android insists that it's not fragmented. Could we also get China's opinion on internet censorship or Rush Limbaugh's thoughts on Obama?
"Sufferin' succotash."
There is no fragmentation problem with Android. It's always been something that Apple fanbois have used to attack Android for being less homogenous. 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.
True early on some features wouldn't be supported on older versions of Android, but the same is true with iOS, Apple adds new features and doesn't necessarily port them to old iPhones.
Well, the wordplay is correct. You could also say that the mobile market is fragmented between iOS and Android, yet we call that differentiation and innovation.
After all - we could create a government mandate that all computers have to be x86 based - that would've stopped a lot of fragmentation. Would it have created a better world?
it's in my head
Oh wow shocking, Apple gained sales market share right after releasing a brand new super-hyped phone and lowering their old prices! Android is doomed! DOOOOMED, I tell you!
Anyways, fragmentation is good for the market. Allows for true competition and drives features. The newest Android phones are far and away more featureful than any iPhone, plus you can choose from any carrier and any range of features you want. I would have liked Google to encourage manufacturers to release more updates to their phones so people didn't get stuck on 2.1 or whatnot, but the fact that most Android programs work on most Android devices is nothing short of amazing when you think about the vast array of different hardware they can contain.
"None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
But per the usual misunderstanding on /. , the general public is not geeky. It does not use hacks or cracks, it does not sideload or use custom ROMs. Most don't even upgrade the SD card, or even know that you can.
The general public picks a phone up and evaluates it, if they evaluate it pre-purchase at all, based on a 1-5 minute poking around on the device. I think the iPhone wins these battles with the average, uninformed consumer because the graphical presentation is slick and the interface is intuitive to the non-techie.
Some people equate smartphone with iPhone. For those who don't, most of them will buy whatever gives them the cleanest presentation and seems easiest to use. Openness and Google and other geek-factors don't enter into it.
My experience has been a little bit different, I used an Android phone for about 2 years and now use an iPhone. I can't name any app that is better on Android. Sometimes they are roughly equivalent, sometimes they aren't, but what is usually the case is that the iOS version is smooth graphically, opens/closes without fits and starts, doesn't creak when interrupted by calls or texts, etc etc.
A good example is the ESPN Scorecenter app. the iOS version is great. The android version is more simplistic graphically, it doesn't wipe or update as well... for me, sometimes it needed to be killed and restarted to update scores.It works well enough, it's just not as polished.
It's probably not the developers' fault, I think there is universal agreement that Android is much harder to develop for. This works itself out in app quality.
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.
Most apps run well on every android version thanks to the design of API cross-compatibility (I have experienced this myself, being an early android developer).
However, I don't think you can avoid the fact that the OS itself is fragmented when your OS takes 6 months to a full year to be available on the majority of android handsets.
In addition, has Mr. Schmid had a look at this chart, put up by google themselves?
http://developer.android.com/resources/dashboard/platform-versions.html
It reads OS fragmentation all over it! And this is PRECISELY what pisses many (geek) users off, that they can't get the latest and greatest or that new phones come to market being outdated!
Oh sorry, I was busy playing my superior games and using my wider selection of apps, to care that your phone has more numerical specs than mine. Geek bias.
Apple adds new features and doesn't necessarily port them to old iPhones.
Apple is pretty good about updating their product line to the current OS. True, you're not going to update your original iPhone to iOS5. But you're not going to buy a brand new last gen iPhone 4 or even iPhone 3GS with iOS 3. Same with Windows Phones, they all currently run the latest release of WP7, even if you buy a last gen samsung focus from. However, in the Android world you can buy a brand new Android phone with an OS 2 versions out of date, and that phone will never be upgraded. THAT is the problem. We're not talking about 4 year old phones not getting the latest release. We're talking about brand new phones that are out of date, out of the box. This isn't a fairy tale.
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 agree that the general public is not geeky, but if their purchasing were primarily based on having a slick graphical presentation and intuitive UI, the new Windows Phone should be winning hands-down. Most of the general public, I'd posit, is heavily influenced by Apple's slick marketing, and a large number buy whatever the salesman at the retail store pushes (which is largely based on sales incentives or his own fanboyism), or what their friends and family recommend.
My experience has been a little bit different, I used an Android phone for about 2 years and now use an iPhone. I can't name any app that is better on Android....
Google maps. Navigation specifically. Voice navigation more specifically.
Android actually reduces fragmentation. Could you imagine what would happen without Android? Every phone manufacturer would have its own completely different OS. If Apple MS and RIM threw in the towel today and all switched to Android there would be significantly less fragmentation in the marketplace as a whole.
The argument that Schmidt is making - manufacturers need to be able to differentiate their products. Android allows them to do this without sacrificing interoperability on the scale that Apple/RIM/MS sacrifice it.
You - bonch/Overly-Critical-Guy - live in a closed bubble where all you can see is "Apple good, Android bad". You have blinders on your eyes. Please either take them off or stop posting.
AccountKiller
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).
you're doing it wrong
AccountKiller
Nonetheless, "fragmentation" is a marketing term being bandied about by Apple apologists.
That's a dangerous assertion to make, and smacks of putting your fingers in your ears and saying "la la not listening".
Android has some absolutely stellar features and plus points but it also has downsides, and to just attempt to "shush" them by claiming it's just Apple apologists does nothing to help Android.
Fragmentation is a problem, and one created by one of the major benefits of Android - the wider selection of hardware that it will run on. iOS minimised the problem by limited the number of devices that developers need to target and test against, which gives you the benefit that apps in the store really only need a couple of branches: iPhone or iPad > Pick one of a few options regarding model. It has the downside of limited model selection compared to Android.
Don't get me wrong, I think Android is in the ascendency and everyone is the better for it (including iOS users), but ignoring constructive criticism is not a sensible way to go about things.
Your wife is also going to be disappointed with whatever tablet she gets if she wants to watch flash content, since Adobe pulled the plug on it.
That's a problem with Android - there are a LOT of sub-par devices out there and people that start off at the low-end are often left with a bitter taste. At least with iOS, the devices are reasonably capable, even the older models. I dare say that the experience your friend with the crappy device had would have been much improved just by moving to a higher-specced android phone, but the important thing is that they're happy.
I'm going to be honest - I'm a big Android fan, but I am a geek through and through. I rooted my phone within a week of getting it and installed a custom ROM the next day - that alone was tonnes of fun for me and a plus to the Android experience. However, when family and friends ask which phone they should get, I'll never say "Get Android, it's da bomb!" partly because I know the reasons I like Android are reasons they'll hate it and also because I don't want yet another device to support. However, I will recommend devices that meet their needs and there's almost always an Android that fits in there, but I'll always say "Go into a store and play with it, ONLY get it if you like it". If anyone buys a phone just because its cheap or because people rave about it, yet end up not liking it, it's really their own fault for not trying before buying.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Pretty much any Google app is better on Android. The way I've viewed it, when recommending phones to people, is that it depends on which non-phone camp you're in. I don't use iTunes, my email is Gmail, news reader is Google News, etc. My music is mostly from Amazon and stored in a folder structure but any major player is able to read the tags. And I've been dabbling in Google Music lately anyway. So Android gives me the best Google experience. The Google+ app is always going to get Android updates and features first, as is most any other app by Google. And like you mentioned, Google maps navigation is top notch. However, if someone has their life in iTunes and would love to have that seamlessly carry over to their phone. I'll tell them they might prefer the iPhone. For what it's worth, my wife just upgraded from a BB Storm 2 to an iPhone 4S. It was hardly a seamless upgrade and she spent the first few days complaining about how much of a pain it was to set up the new phone and make it do what she wanted. She even said at one point that it was easier to set up the BB than the iPhone! Ultimately I don't think there's that much of a difference anymore either. Both are a phone with a button and a bunch of app icons. Both get you on the web. Both have Facebook. However I've yet to still see anything really that the iPhone does better than my Galaxy Nexus.
This is the mother of all failed analogies. All of the devices you mentioned are interoperable and standardized in very important ways. Why do you think all Ryobi batteries are interchangeable? Why do you think all cars have the same basic layout and conform to the laws of the land? Why do all tv sets have the same basic standardized ports and display the same basic standardized signal? Why does just about any thermostat work with just about any furnace?
As an iOS developer, Apple has made it really easy for me to write code once and I know I only have to test it on about 3 devices. From there I know my addressable market is hundreds of millions of devices.
As a consumer I have confidence that when I buy a new iPhone in 2 years, all the apps I pay for today will work in the future. I don't hesitate about making the investment because I know it can be long term. And I don't have to go setup my phone from scratch either.
Kiteboarding Gear Mention slashdot and get 10% off!
I'm not the AC to whom you replied, but I did the same thing s/he did. Had an iPhone, switched to Android, and switched to a 4s as soon as my contract was up.
The reasons for moving to Android were openness and ability to side-load. It turned out, these weren't that big a deal.
First of all, ideologically, Android isn't really open for me. It's open in the same way that Tivo is open. Parts are based on Linux, other parts are new. Some of it is available to me, some of it isn't. But what matters (to me) is that I can't just download the source, compile it, and end up with a working build. At BEST, with a lot of work, I can get something on my phone which resembles the original (minus e.g. Google's apps, which are half of the reason to get an Android phone to begin with.) At worst, the phone has a locked bootloader, and you can't put a new ROM on there.
If my two choices are both effectively closed, then the openness of the platform is irrelevant.
I also found that I never cared to sideload. It wasn't difficult to do--I just never had a reason to. And all of the apps I had on my phone would have gone through the Apple App Store approval process--I wasn't doing anything really off the wall. So I had no need to sideload.
Then there's the issue of upgradeability. I figure that my Android phone would have been vulnerable to known exploits for about 1/4 of the contract. That's due to the carrier/manufacturer failing to update in a timely manner. The build process is fairly onerous, so I wasn't going to do it myself. Going with Cyanogen, I got updates faster. But I don't want to have to do that. Apple updates very old hardware to new OSs. Their time-to-fix vulnerabilities isn't much (if any) worse than Cyanogen.
So at the end of the day, I had to decide based on features. Both Android and iOS do what I want them to, but iOS does it cleaner and smoother.
If you are not documenting and validating the input methods of your methods (regardless of whether they are public or private) then you are making a colossal mistake. How do you know when the maintainer who comes after you is going to refactor the class; answer: you don't. If you are not validating your inputs and thinking out the overall object state when you first write the method just because you're too lazy to then no wonder people like myself are forced to re-invent the code people like you write. I *hate* re-implementing code that other people have done, but it turns out that people that don't design for re-use by others (that is, hide methods that are required to extend functionality while maintaining invariant conditions) are the majority and mistake the contrived examples given in textbooks (showing you how to hide *critical* methods) as examples take this as what should be done for *all* classes.
You are welcome to think I'm full of it. Like I said, I used to think as you do, but with a lot more experience of using other's code I realized how unfriendly this is for third-party devs trying to use your code (who will need to re-use it in ways you never thought of - thanks to their particular requirements). For example, just try extending JavaMail to allow to arbitrarily muck around with MIME mail parts and nest them as you see fit. Turns out the methods you need to do that are all implemented but hidden away, yet looking at the source (thank goodness I had access to it - not always the case) there was no good reason for hiding it away that I could see, apart from it being 'orthodoxy' (which means the author never thought about it too hard, as they probably never had to try using his own code while trying not to access the source, as a user would try to do). In the end I had to wastefully re-write a chunk of Javamail for the clients use. This kind of crap is why 'Not Invented Here' is so prevalent - because orthodox Java development as promoted by the textbooks and circuit speakers goes too far so as to make encapsulation a straightjacket. Some encapsulation is good, but too much is worse than too little, if you know what you are doing (as most professional Java devs do these days - which is why it is so frustrating). Basically I see the excessive hiding of information as an unhelpful 'denial of service' by the author - maybe because they are too damned lazy to document the method, validate its inputs, or test it in isolation (of course getter/setters [accessors/mutators] don't need this level of work), and it sucks when I have to re-implement what they did just because they unnecessarily closed off a few very helpful methods. I'd bet you money that if you've been developing for a while you've had this yourself. One last thing, when developing a class I believe you should always be thinking of how the class could be used in a stand-alone fashion (as any Java Bean can be) without the rest of the machinery of your particular application. The corollary is that the smaller the dependencies (example, choose JRE standard classes like java.util.logging over third party libraries) the easier it is for other people to use. Most Java developers don't try to minimize their library dependencies and think whether each library contributes enough to justify the extra weight, but they should. This is why some small Java programs come with hundreds of extra JAR libraries, some of which have very tenuous utility for the application (and sometimes a single class is used from a library, which brings in a raft of other libraries, when a simple implementation of the simple class would have saved the dependency mire).
I understand what you are saying. I just happen to disagree that methods should be hidden by default. With proper documentation and unit test examples for client developers to follow (you do unit test, don't you?) then trying to 'protect the developer from themselves by hiding functionality' becomes unnecessary - which gives the client more freedom to use more of your classes, and therefore the client