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
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...
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.
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.
That's great until you realize some things can't be lowest common denominator.
And Desktops are a bad analogy, let me give you an example:
To make desktops analogous to the mobile phone market - you can run multiple apps (multitasking) but can only have ONE on screen at any given time. That means the app take up the whole screen, and do so gracefully. This is great for web browsers, but how many apps do you know that scale well when they're stretched to random dimensions they weren't designed for? Oh, I'm sure they're usable, but do they look good or professional? Probably not.
Now take it to mobile phones.
Now take things like input paradigms. Is the user going to expect a multitouch system to interact, maybe not? Well if every app assumes not, then why the hell sell multitouch to begin with! Oh, so we should support multitouch but degrade to single touch, well, okay, that requires different UI input systems different UI design quite possibly, etc. Do you start to see the confusion here?
For devices like phones, monoculture within an environment can be -VERY GOOD- for developers, because it reduces the specs you have to target, and because the device and apps have to be integrated in a very deep way. On operating systems, monoculture tends to do bad things though, because you end up with no options or creativity present.
I'm not saying that the monoculture should be Apple, I'm just saying if all the android phones had to meet X requires and all had X resolution screens, and all of them has X input systems, and the extras were in size, and things that don't effect applications, you'd have a much more workable development environment.
Just my $0.02, as a mobile application developer...
I agree, in fact there was a blog article written by an android game developer that kinda mock'ed this notion of fragmentation.
Quote from the blog: "I'm lucky enough to have occasional access to lots of different Android devices via my work. The whole point of the Android approach to apps is that you can write an app on one device (or even an emulator) and deploy it across everything. In my case, that's been pretty true."
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.
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.