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."
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 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!
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.
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
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
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!
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