Slashdot Mirror
Fragmentation vs. Obsolescence In the Android Ecosphere
whisper_jeff writes "Engadget has an interesting article up discussing whether or not Android is fragmenting. While the article discusses the concept that it may be more about handsets becoming obsolete at a dramatic pace rather than the OS fragmenting, it also begins by noting that there are currently five different versions of Android on the market, which implies there is a notable degree of fragmentation. Regardless of it being fragmentation or handsets becoming obsolete to new feature sets in a terribly short period of time, I believe this development cycle could turn casual consumers away and hurt Android's chances for long-term mainstream success."
The flash runtime has experienced the same problems as it was a developing platform. Flash 8,9 and 10 are all still in use today and have different feature sets and programming models. I realize the analog is slightly different as android is an OS and not a runtime, but the fact remains that progress requires this. We as geeks bemoan long development cycles and slow progress. Well the way to get around slow progress is quick iterations, and that gets to you to fragmentation. Adobe has realized this and their rate of development has slowed as they have stabilized on where they want the platform to go. Give android a year or so, and once Google realizes where it wants android to go, the iterations should slow down dramatically, and fragmentation will be a thing of the past.
je suis parce que j'aime
Arguably, there are two broad classes of users/applications for Android: the ones that need a cheap phone OS that sucks less than your average "dumbphone" or "featurephone" OS(both in terms of general usability, and in terms of the dev team's ease of getting things going) and the ones who want an "Android smartphone", and wish to run "Android applications" on it, and so forth.
You would expect the former group to be heavily fragmented; but for that fragmentation not to matter very much. For any device where Android is simply being used as a cheaper or easier alternative to a dumbphone/featurephone OS, or even to some other embedded operating system(as with a cheap digital photoframe or GPS or something), the version, and most likely the applications, the device ships with will be the ones it dies with. Fragmentation will be inevitable; but also won't matter much(upgrades will generally not be expected, outside of a few tinkering geek who can roll their own, device developers will use the Android version of their choice when developing. No big deal.)
The trickier case is the part of the market that directly competes with iPhones. Here, updates are generally expected, adding applications and having things work is a prerequisite for success, and fragmentation is a bad thing. Google's own blessed handsets seem to be avoiding this reasonably well(within the limits of hardware advance. The G1 is starting to show its age; but so is the gen-1 iPhone); but some of the tier-2 carrier stuff is looking a little more doubtful.
Personally, I suspect that the critical thing will be whether or not expectations are correctly matched to devices. Having more or less fixed-spec "featurephones" being based on Android isn't bad for Android unless those phones are then sold to unwitting buyers as being equivalent to the high-end, frequently updated, fully app-compatible "Android Phones". If they are just sold as featurephones with decent browsers and mail clients, no harm, no foul. If they are (essentially dishonestly) sold as cheaper-but-equivalent alternatives to the properly updated Android devices, there will be a lot of unhappy customers stuck with outdated firmware.
Actually, you can build with a modern SDK while having a minSDK attribute set to 3 (android 1.5) so your app will be compatible with android >=1.5 (99.9% android phones are 1.5 or newer), and on 1.5 you can have access to so many things, it will be difficult to really have a need of doing something which is not possible.
Live wallpapers and maybe some advanced graphic functions will not be available, and the hardware of those "legacy" devices won't be able to handle that, anyways.
So there are only a few things left which are not possible, like account manager integration, the cool Log.wtf() function and a few more, but nothing extremely important, I'd say...
...But is phone manufacturer. If you make the phone and it just runs a vanilla Android OS, then you can theoretically push the update out without too much pain. The problem comes from the phone manufacturers who are trying to "improve" the OS by adding things like Sense UI and Motoblur. Yeah, some of these improvements are better, but others aren't any better than what comes in vanilla, and even more are worse. The fact that the modding community can turn on OS around in a few weeks and push it back out to the device is testament to how easy it is to put these newer versions of software on the phone, and it just the manufacturers trying to add their own crap back on that is the issue.
These "growing pains" need to be worked out, but app developers will quickly learn to check versions at runtime to make sure most of their features will work in older (or newer) versions of Android. Apple took care very well from the start, but they've had lots of consumer software experience. Goole & Android will get their act together ... it will just take a little time.
I thought Apple's approach was to strictly control both the hardware platform and the developer's tools, both to ensure they will work together and also to make it highly inconvenient for developers to port their apps to other platforms like Android. That sounds like marketing and vendor lock-in experience. The term "software experience" seems to suggest that they have tackled the complexity involved with developing for diverse systems instead of avoiding it.
It is a miracle that curiosity survives formal education. - Einstein
By this summer you'll have to support the 1G, 2G and 3G versions of the iPod touch, the 1G, 2G and 3G iPhones, the 3G iPhone with more RAM and a faster processor, and the 4G iPhone with both more RAM and a higher resolution. Oh, and the iPad of course.
The biggest new challenge with "iphone 4g" is the higher resolution - some say this will be 960x640 (i.e 2x the current resolution hor/ver), which is imho unlikely as this would be the first use of such a LCD resolution ever.
To me this doesn't sound simpler than the Android fragmentation, at least with Android the market lets you know which apps you can install, and the vast majority actually works with 1.5. With the Appstore you might only get "oh, don't install this on an iPod touch, it won't work".
Android is also more developer friendly, e.g. the new feature introduced just before the 2.2 release - at least my N1 got a "report this crash button" before I upgraded to 2.2. (I don't want to speculate on the developer friendlyness of Apple, but recent news haven't been very good.
You can specify the hardware and software requirements of your app in the manifest file and it will not show up in the market for devices which do not meet the requirements.
You can be incredibly specific. If you app requires an auto-focus camera then you can specify that and it will only show up for phones which have one.
Dont be.
Fragmentation is mainly FUD. Android applications operate via the Dalvik virtual machine meaning the vast majority of applications will happily run on almost all hardware. Only when you start writing applications that require access to a version specific API does this become a problem, most of Android's API's are version agnostic. The simpler your application the fewer issues you will have with it, the so called "issue" of fragmentation is only true for the most complex of applications, if you are writing a simple XML parser then you wont have a problem.
Calling someone a "hater" only means you can not rationally rebut their argument.
I agree to some extent. Though I think it is a fools who runs in the sight of adversity. This doesn't mean that the environment is adverse, on the contrary, it is far from adverse. Engadget has no clue, they don't know what they are talking about. The Andriod is no more fragmented than Windows, the Mac OS, the iPhone, or any other. They are making much ado about nothing. Fire the editor for ruining the careers of the journalists by publishing this crap!
One has to expect fragmentation and that the fragmentation will decline as models age out. Those consumers that don't have a phone with touch will just give up the ghost and get a better more modern phone over time. Apples OS4 for the iPhone won't run on the first two generations of the hardware. The coming updates beyond OS4 will fragment the iPhone more, and that's coming from "one company".
Let's be real. The talk about fragmentation is a marketing ploy by the competition to keep developers and consumers from making the leap. An intelligent mind sees that fragmentation is everywhere from the desktop to the phone--in every device and in every OS.
You can lead a man with reason but you can't make him think.
The fascinating thing about "fragmentation" is that it's a problem we just made up. Apple's Mac line, let alone the Windows world, have more hardware and software diversity in one minute than Android has all year. Yet no one goes around suggesting that "fragmentation will hurt the PC market's long term chances of success."
This feels like a FUD bullet point created by an Apple astroturfing firm, whether it actually is or not. The whole "fragmentation" line of thinking presumes a world we have never had, and which I doubt anyone would willingly choose: one where a single manufacturer rules, producing a few nearly perfect products in a graceful, gradual schedule.
The funniest part is that this meme is useful for identifying people with no Android developer experience. After having used both the Apple SDK and the Android SDK pretty extensively, you can see why Android will win in the marketplace, and win so quickly. Never has there been such a beautifully organized, transparent, open, easy zero-to-development experience. In a world where most platforms don't even think about API versioning until it's too late, Android builds in an elegant management system from the beginning. "All 5" API revisions are accessible via a pullout menu. You default to the lowest, so that your app is compatible with all devices. Easy done.
And if you need something that a newer OS revision offers, everything about it makes it easy to target the minimum revision required.
The documentation is organized and straightforward. Running and debugging your app is a keystroke away, with a hardware-level emulator that's trivially configured to match whichever devices you prefer to test on - or all of them.
It's ironic, really. Hardly anyone has ever done such a good job of managing fragmentation, yet all this refinement for a platform that has less diversity (especially at this early point in its life) than almost any open platform I've seen that's this widely used.
In short, LOL.
Tired of Political Trolls? Opt Out!
The only people to be hurt by the 'fragmentation/obsolescence' issue is developers. I don't want to downplay the developer issue, but as far as consumers are concerned , most of the big-time apps have no trouble supporting multiple iterations of the platform.
On the contrary, please do downplay the developer issue. Obviously, it matters a great deal to us as developers, but the purpose of hardware and software -- at least in the commercial market -- isn't to please developers, it's to please customers so they'll give money to the companies that employ the developers. If enough customers want a device that requires the developers to read documentation in cuneiform and write code in assembly language, then we'll be reading documentation in cuneiform and writing code in assembly language, or the software companies will find someone who will.
Don't get me wrong; *I* care about these issues as much as the next developer. But nobody but us cares about these issues or what we think about them. For the vast majority of us who don't work at mythical miracle companies that actually give a wet crap what their programming staff thinks, we'll end up coding for whatever platform the bean counters and bizdev monkeys decide is going to sell. And if they're wrong -- a decision that's ultimately going to be made by consumers with even less technical knowledge than the bean counters -- then we'll end up working on something else, possibly at another company if the last one didn't have enough capital reserves to withstand a product failure.
That being the case, the author of TFA is either out of touch with the reality of the industry or, as several posters have suggested, this is just astroturf FUD designed to scare consumers away by using long, scary words -- like fragmentation, for example -- whose meaning they don't know, just as most of them probably have no idea what an operating system is or that Android is an OS. I'd be willing to wager a decent chunk of change that most non-technical customers would read the headline and the first couple of sentences of TFA -- they're certainly not going to read the whole thing -- and conclude that the gist of the article is that Android phones are more likely to physically break into little bits than iPhones.
Proud member of the Weirdo-American community.
And then one person with Android A can download it and tells their friend with Android B about it. Android B user goes to the market place and can't find or download that app and gets pissed off. It happens more than you'd think with a friend of mine. He has an HTC, his wife a motorola with the keyboard so she can send 500 texts a day. They've come across several apps that will work on his phone, but she can't even find it in the market place.
As a developer, we're charging 4 - 5x's the price for an android app vs. an iPhone App. Reason being that Android is more expensive to develop for due to the number of phones on the market all with different OS & hardware specs. Since august of last year, we've spent over $6k now on Android and sets. To give you an idea, we spent $2500 from 2008 - present for iPhones and iPod touches.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Someone want to explain to me what makes this "Interesting?" Or for that matter, what makes it at all relevant...
Because the people providing the operating systems for mobile devices are discovering, to nobody's surprise but their own (and apparently yours), that being able to manage and maintain a software base over a diverse number of architectures and platforms is a non-trivial task.
In my professional experience, the inventors of apt-get were the first to create an adequate means of maintaining a largely stable system, managing compatibility and dependency issues over tens of thousands of applications, utilities and drivers.
The implication of my statement, therefore, is that Google should be giving more thought to package management issues as a means of reducing their own software maintenance overheads.
Unfortunately, that's not likely to happen in any useful way, because all the phone suppliers only dream of being Apple, so they're intent only on controlling every means of access to the apps and other software that runs on their phone.
Therefore, these vendors - who fail to understand why apt-get is important - are condemned to creating their own proprietary update services and interfaces, and because they are neither unified nor open, it's quite likely that each of them will get it wrong in unique and entertaining ways.
That one little sentence took a bit of unpacking, but there you go.
HTH, HAND.
Crumb's Corollary: Never bring a knife to a bun fight.
Fragmentation is a non issue. Don't target the latest version, and life is good. Target the latest version and your market shrinks. It's not that hard. Oh, and anyone who says you have to buy a bunch of phones doesn't know how Java works.
-- $G
He has an HTC, his wife a motorola with the keyboard so she can send 500 texts a day. They've come across several apps that will work on his phone, but she can't even find it in the market place.
She should try again. From the sound of your post, it sounds like you're located in the US, and she has the Motorola Droid. That means her phone was upgraded to 2.1 a couple of weeks ago, and will probably get the 2.2 very soon.
And anyway, there isn't really a big difference between 1.6 and 2.2. 1.5, yes. And anything below 1.5, no one is using anyway. And unlike the iPhone, which is changing its complete underlying architecture as we speak, the Android SDKs on the other hand are stabilizing, for instance Froyo is even being delivered six months ahead of schedule, and there are less and less changes that developers are clamoring for.
And when I can't find an app that someone recommended to me, that's usually because many apps that were free a few weeks/months ago have transitioned to fully paid apps (and the developer has removed the free/lite version off the market as a way to get more sales, since he already has the word of mouth going for him, and the people that miss the free app can't leave new comments anymore -- unless they pay for the app at least once).
As a developer, we're charging 4 - 5x's the price for an android app vs. an iPhone App.
Hey, charge whatever the market can bear, that's what I say. Currently, there seems to be a big shortage of Android Developers on most job sites. So please, charge away. It's a good way to weed out the overflow of clients. And right now at least, taking on clients that want to commission an Android App is much more lucrative than making your own app (later on, that will probably be the reverse situation, but I'm only speaking of right now).
Since august of last year, we've spent over $6k now on Android and sets. To give you an idea, we spent $2500 from 2008 - present for iPhones and iPod touches.
This misses the point that you can only develop for the iPhone/iPad only if you're on a Mac (for the most part). And that's fine if you already have all the Mac equipment you need, but for many of us still, we still have Windows machines or Linux machines, so the barrier to entry is much lower on Android (not to mention the registration fee to be able to develop on the Market as opposed to the App Store).
Also your entire testing strategy should be based on the type of Mobile Application you're making. For some applications, testing for every variation makes complete sense, for instance, if your application depends on the camera, it makes sense, for others, it simply doesn't. Besides, developers are organizing to share testing devices among themselves. Some companies are crowdsourcing testing and QA. And if you're near a Google office, and go to some of their events, you can usually check out devices from them free of charge. So if I were you, I'd hold off on buying the 39+ Android phones or the 50+ different Android devices that will be available this summer, and depending on the type of Application I was making, I'd give my client an itemized list of prices for the different SDKs that are out there, and let the client decide on the cut off point, on the type of support he wants to have, or not have.
In other words, I have experience with Android including very simple android development and do not believe the scaremongering caused by this so-called fragmentation.
Which, unlike your quotation, is not removed from it's context. How, did you somehow read that I didn't say "fragmentation" isn't a big issue? When the vast majority of developers will never encounter it, fragmentation is not a big issue.
Android's application framework is based on the Dalvik virtual machine, if your are unfamiliar with how virtual machines work they serve as an intermediary between the hardware (or the HAL) and the application, the virtual machine is written for the hardware, the application only needs to be written for the virtual machine providing an identical framework for applications across divergent hardware platforms and versions. Finally, yes, Dalvik does this quite well.
So take you scaremongering and out of context quotations elsewhere good sir until you actually learn about the "problems" you are spreading FUD about.
Calling someone a "hater" only means you can not rationally rebut their argument.
No cross environment or VM can replace actual testing on actual target hardware. No matter how closely manufacturers claim to follow the specs, quirks always manage to work their way in, and sometimes these quirks cause things to run differently. A serious development house will want to validate their code on all major versions of the hardware, esp if those versions come from different manufacturers.
That's why everyone who programs for Microsoft Windows has to have a test example of every single make and model of PC that's ever been manufactured to test their programs on.
Oh, wait...
I'm old enough to remember when discussions on Slashdot were well informed.
Do you seriously think all PC developers buy 15", 17", 19", 21" and 24" monitors just to test their apps at different resolutions? Or every single graphics card made in the last 10 years by nVidia, ATI, and Intel? Maybe a few specialty app developers like Adobe and AutoCAD buy a representative set, but for most apps it just doesn't make enough difference to matter. If a device is sufficiently different from the norm in the market that a whole bunch of apps break on it, that device will be the one with the bad reputation, not all the apps that fail to run on it. Yes, it may be a bit of a support headache until that device's flaws become apparent to everyone, so take account of that in your cost model and charge accordingly. At least that's within your control, as opposed to iPhone App Market approval.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire