Fragmentation vs. Obsolescence In the Android Ecosphere 315
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."
Scared iPhone developer (Score:3, Insightful)
I wouldn't be able to keep all the chargers straight anyway.
Re: (Score:2)
I don't feel like buying enough handsets to cover my desk.
I wouldn't be able to keep all the chargers straight anyway.
Just get a used vending machine, put each phone into a 'slot', attach the charger cord with a loose zip-tie and you're all set. Heck, if you set them each to cost $1 you'll save up enough for the next handset in no time ;-)
Re:Scared iPhone developer (Score:5, Interesting)
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...
Re: (Score:3, Informative)
There's hardware heterogeneity issues also, though: some phones have multitouch and some don't, for example, and the processor speeds and screen sizes are different. Even for devices with the same sensors, the sensors can behave differently, e.g. what kind of control over the camera you have and what data it feeds you, and what the accelerometer's characteristics are.
Doesn't matter for a decent number of apps, but matters for, say, mobile games.
Re:Scared iPhone developer (Score:5, Informative)
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.
Re:Scared iPhone developer (Score:4, Informative)
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.
Re:Scared iPhone developer (Score:5, Insightful)
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.
Re: (Score:2, Funny)
Hey troll.
It's refreshing to see someone announce their intentions up front...
Re: (Score:3, Informative)
Re:Scared iPhone developer (Score:5, Insightful)
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...
Re: (Score:3, Insightful)
The GP said ALL MAJOR VERSIONS, not every single version.
As an iPhone developer I have to agree with the GP. Android is not an environment with a standard windowing system, or with standard inputs. On Android you have lots of different resolutions, different input methods, and several major versions of the OS in the wild.
If you are committed to creating a good app that is well designed and has a good user experience, you are going to need to buy several handsets.
And as a hobbyist programmer this actually ma
Re:Scared iPhone developer (Score:4, Informative)
More testing than that is usually required.
Say you want to release it in three language markets. A more complete test might want:
Windows 7 x86, English
Windows 7 x86, Japanese
Windows 7 x86, Russian
Windows 7 x86_64, English
Windows 7 x86_64, Japanese
Windows 7 x86_64, Russian
Vista x86, English
Vista 7 x86, Japanese
Vista 7 x86, Russian
Vista x86_64, English
Vista 7 x86_64, Japanese
Vista 7 x86_64, Russian
XP x86 single-CPU, English
XP x86 single-CPU, Japanese
XP x86 single-CPU, Russian
XP x86_64 single-CPU, English
XP x86_64 single-CPU, Japanese
XP x86_64 single-CPU, Russian
XP x86 MPC, English
XP x86 MPC, Japanese
XP x86 MPC, Russian
XP x86_64 MPC, English
XP x86_64 MPC, Japanese
XP x86_64 MPC, Russian
Needless to say, few companies test all the possible combinations.
Oh, and probably both home and business versions too. And a couple of server versions.
And, if using graphics, with the most common graphics card variations -- at the very least the last 2-3 generations from nVidia, ATI and Intel. Repeat for sound if applicable. Then you repeat the tests with and without Administrator rights, and with and without UAC enabled.
If you really want to be nice, you also test with accessibility features, different DPI settings, and a tablet PC too.
Yes, there's fragmentation in Android. No, it's not even CLOSE to the fragmentation in the Windows world. Sure, it can be frustrating to port a cell phone app to run on a nook, but at least you know what the nook is going to be like -- it's not like a user has changed the DPI settings, runs a Danish business version of the OS, has replaced the sound card, and uses a 5 TB RAID instead of a micro-SD card.
Re: (Score:3, Funny)
This is an *apple* developer we're talking about here. You must only help them find ways of *reducing* testing complexity. For example, so that you only have to test with one mouse button.
*rimshot*
Re: (Score:3, Informative)
So you're a commercial Android developer, then?
Didn't think so.
There are all manner of bugs that can show up in an application that are dependent on the exact configuration of the Android device you're working on. Test an app on the stock Android emulator and it just works across the board, right? Wrong. An obscure quirk of the way the input method works for the custom keyboard on Samsung devices makes it crash in an embarassing way. The UI's thrown out of kilter by a different size status bar. All sorts of
Re: (Score:3, Interesting)
There's hardware heterogeneity issues also, though: some phones have multitouch and some don't, for example, and the processor speeds and screen sizes are different. Even for devices with the same sensors, the sensors can behave differently, e.g. what kind of control over the camera you have and what data it feeds you, and what the accelerometer's characteristics are.
Doesn't matter for a decent number of apps, but matters for, say, mobile games.
This is mistaken, actually. They all have hardware multitouch, some don't have software multitouch enabled for legal reasons. But as people upgrade to newer versions of the OS, the multitouch magically appears! Also, as the virtual machine has got considerably faster, my original G1 is now much more performant than it was when new, and thanks to the nice folk at Cyanogen it already runs Eclair and will soon run FroYo. Yes, there probably are differences in the actual physical characteristics of things like
Re:Scared iPhone developer (Score:5, Interesting)
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.
Re: (Score:3, Insightful)
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.
I think this is the whole point of the fear. When you invest in creating a complex app you want to know it's going to work for everyone. There's an inherently higher risk involved with developing for a platform with such varied hardware & software.
Saying that the fragmentation isn't an issue is glossing over the problem. Kind of like saying there's not fragmentation in desktop computers because you can run flash apps the same across different operating systems. Not every app developed is a fart soundboa
Re:Scared iPhone developer (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Anyone who says you DON'T have to buy a bunch of phones doesn't know how development works.
Yes we know it will technically run. But considering screen size/resolution/layout/keyboard (or not)/etc differences you really need to test your app on each representative phone. While not EVERY phone is necessary, you'd need at least 4-5 to cover the combinations.
Re:Scared iPhone developer (Score:5, Insightful)
Re: (Score:3, Informative)
That's completely different. On a computer, it's acceptable to have an application running in windowed mode and not taking up the whole of the screen. That is incredibly uncommon on a mobile platform - all apps are expected to use the whole of the screen. This very simple fact alone alters development considerably.
Re: (Score:3, Insightful)
LOL. You use a Windows Mobile [htc.com] phone to make your point about Android? Please. ROMS? What is this, 1988 and we need to cook up a bios upgrade?
There are about 50,000 apps in the Market. It ain't that difficult.
Yes, it is up to manufacturers to release updates. That's why you don't target the latest versions, just like EVERYONE in the Android developer community recommends. And yes, sometimes a manufacturer will have a flaky phone. It doesn't happen that often. If you don't like getting cut, don't sit on the
Re: (Score:2, Insightful)
"Mostly FUD", "the vast majority", "most API's"... In other words, there is truth to the claims of problems caused by fragmentation.
Re:Scared iPhone developer (Score:5, Informative)
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.
Re:Scared iPhone developer (Score:4, Insightful)
Amazingly you seem to be the only one who sees this.
You are spreading Fear, Uncertainty and Doubt over the issue which is quite clear cut. I refuse to speak in absolutes because there is no such thing. Further more you fail to disprove my point and you are only spreading FUD, this is obvious for one simple reason
You have not attacked my point, you have only attacked me.
Re: (Score:3, Insightful)
Had I quoted you out of context, you'd have a point - but I quoted you exactly.
Interesting comment. You don't even know what it means to quote someone out of context, do you? The fact that you quoted him exactly doesn't mean you didn't quote him out of context. You need to get some more facts straight than what is obviously a lack in knowledge about Android development. Basic language skills would be a good place to start.
This is Apple's most successful FUD astroturf (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
The fascinating thing about "fragmentation" is that it's a problem we just made up.
Exactly. Too much dumbing down is also to blame here. Any competent developer should be able to easily structure his/her application so that it detects at runtime what feature set is available and then adjusts itself accordingly. The APIs are all there and they are very well done. It's not like it's even a problem.
And finally how is this different from Apple devices - some have cameras and some don't, some have bigger displa
Re: (Score:2)
You described the iPhone development experience as well, and are yet to mention one way in which android development is more of a "beautifully organized, transparent, open, easy zero-to-development experience" than Apple.
It might be so, and I have only just delved into Android a bit, but Xcode is such a great dev environment. I hate having to go to work and use Visual Studio to work on piece of shit .Net stuff.
Re:This is Apple's most successful FUD astroturf (Score:5, Insightful)
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...
Re: (Score:2)
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."
Actually - that's long been a claim of the Mac faithful. The Wintel world was just too complex due to no control over hardware. Apple's world was a comfortably controlled world of predictable product lines. This is just re-application of the same mindset to a new market.
Re:This is Apple's most successful FUD astroturf (Score:5, Informative)
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."
Re:This is Apple's most successful FUD astroturf (Score:4, Interesting)
Apple = red herring.
Even worse, there's a huge elephant in the room. The crux of TFA is that fragmentation is the price paid for "the pace of innovation." But the problem is not new releases -- it's the failure of Google's Android Market (app store) to keep up with the needs of the marketplace. This has caused a bunch of carriers, hardware makers, and iTunes-wannabes to create their own app stores [slashdot.org] -- each with their own requirements and generally making life hell for developers. The reason is that Google's own Android Market was slow to launch internationally (especially to support paid apps), has an infamously poor UX, and -- shocking for a company called Google -- poor search capability.
New hardware and OS releases are generally welcomed by developers. But if you're an Android developer, what's insane is having to support multiple app stores for the SAME hardware and SAME OS -- just because Google didn't bother to support paid apps in Canada until two months ago, for example. And don't even get me started on the joys of trying to make an app for China [slashdot.org].
Hey Andy, before you pass off fragmentation as a necessary part of innovation, take a stroll down to the department responsible for creating Android Market and tell them to start innovating to rein in the chaos they've created.
Re: (Score:2, Insightful)
Whether your hardware is supported by software or not has nothing to do with fragmentation of Linux. In fact, there is only one display / window system in serious use on desktop Linux (X.org). The display manager handles your monitor. Nothing else in the stack really matters.
Re: (Score:3, Insightful)
So, my application cannot depend on a feature from 2.1 if I target 1.5; if I want to make use of such feature, my application still must work without it. Is this correct?
Correspondingly, then, if I target 2.1 because my application requires a specific feature, then I cannot expect customers with 1.5 to use it, right? How is this not fragmentation?
Are you implying that every single feature, on every single version, on every single device is optional, so that I can just make my application use it if it's th
Re: (Score:2)
I haven't done much Android development, but it's not as bad as it sounds. I started learning from a Android 2.1 book; all the sample code ran on a locked-down consumer 1.5 handset, 1.5 being the oldest version in common use. The one exception I found was a flag that told you if you were entering or leaving a given physical area didn't seem to be present on my 1.5 headset, but querying it didn't break anything.
Android versions are like .NET versions; you can change the one you want to target, and your cod
Re: (Score:2)
As an iPhone developer who would love to make the jump to include android I am very scared about the large mishmash of versions and hardware.
If that scares you, PCs must be your worst nightmare. Android is a monoculture by comparison.
Re: (Score:2)
maybe you should try looking. the shit is quite well documented and not at all as complex as your spin is implying.
Ignore "blogs" (Score:2)
IMHO idiots like these manage to trick developers causing millions of dollars in potential revenue especially with independent developers.
You don't need to jump the ship, keep shipping for iPhone and add Android, Symbian and even Windows Mobile to your platforms. Ignore what those "blog writers" and fanatics (including some devs) say, see yourself...
Let me give a 2 applications as example: Nimbuzz and Fring. OK, they get great venture capital these days but it is likely 10 guys coding. They ship to any mobi
Re: (Score:3, Insightful)
iPhone apps sell to a combined market of iPhones, iPod touch, and iPad.
There is little fragmentation on the iPhone market. 90% plus are running version 3.0 or higher.
RIM sales are larger than iphone but our iphone app outsells the RIM version by about 5 to 1. RIM users are just not as likely to buy apps. Android US sales are substantial but not yet clear of the trend going forward. It will be interesting to see how things shake out in one year or so.
Re: (Score:3, Insightful)
fragmentation spells out one thing for Android: FUD.
it's called: we don't have anything else to complain about, so lets imply the shit is weak (when it's running quite strong and becoming way more polished than iphone).
But yeah, linux is uh, dying too! I mean, fragmentation!
Give me a break.
Re:LOL! No One Wants You Retard (Score:5, Insightful)
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.
Re: (Score:2)
Yes and no.
1- Android versions are coming faster than any other mobile OS, and OEMs are not great at making new version available for older phones. I'm not sure devices age out faster than new versions are coming out right now.
2- Android covers a huge variety of hardware platforms. CPU, screen size, multitouch, keyboard... not much can be taken for granted. The OS can only hide some of those disparities. Of course Android is not the only one with that problem, but they're having the more acute version of i
Re:LOL! No One Wants You Retard (Score:4, Insightful)
Most of the features that you indicate as being variable on the Android platform are also variable on PCs. Yet, somehow, application development on the PC has not died and software developers have coped despite Apple having full hardware and software control on the competing Mac platform. Is the CPU on the original iPhone still the same as that on the iPhone 3Gs? Is the display resolution the same on the iPhone as on the iPad?
The Android market is certainly different from that of the iPhone, and will require additional skills and practices. However if the response of established iPhone developers is to shun those added challenges, then all it does is open the door to those who are willing to tackle them.
What if App Store intern fragments him? (Score:2)
Who knows if Apple guys hunt him down and reject his next update nitpicking on some minor issue since he said "he wants to jump the ship" ?
Having an actual risk like that is worse than fragmentation, I bet even 8 bit era ASM coders didn't have such a risk.
It's Early In Android's Market Life (Score:2, Insightful)
Apple took care very well from the start, but they've had lots of consumer software experience. Goole & Android will get their act together
Re:It's Early In Android's Market Life (Score:5, Interesting)
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.
Re: (Score:2)
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.
Most app features will work on most iProducts ... but not all. When iPhone 4.0 comes out this summer some of the newer features won't work on earlier handsets (ie, multitasking won't work on a 3G or earlier handsets). Yes, Apple is evil for their lock-in, but I was referencing the article's main subject, which is fragmentation & obsolescence due to handset and OS vertsions.
The term "software experience" seems to suggest that they have tackled the complexity involved with developing for diverse systems instead of avoiding it.
Their Macintosh consumer software experience. They've had a lot of years of practice making sure most, but not all, software runs on
Re: (Score:2)
"...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."
AFAIK, they already do. You declare the minimum API version in the application manifest. All Android versions in use today (1.5 and upwards) are backward-compatible, so if you as a developer wants to maximise the number of users is to target the lowest version that still supports the features your app needs. Which, for most of them, is any version currentl
Re: (Score:2)
I think Android will end up thrashing its problems out probably by the end of this year, or first quarter of 2011, as the OS goes from having to be deployed as fast as possible to get marketshare before Apple locks down the market like they did with MP3 players, to changing to a mature app platform that is decently supported across handset makers and cellular carriers. Android 2.2 has taken some steps to get there, but what it will take is getting to where the iPhone OS is right now when it comes to encryp
Re: (Score:2)
You make some good points but you yield too much success for Android to the business market. Far more consumers use cells than business does, if not thousands to one then millions to one.
Re: (Score:2)
And Apple's computers and other consumer devices, including the iPhone are fragmented. Please stop using them as a bastion of solidarity.
Re: (Score:2)
I have to laugh at this because it smells of the finest astrotruf: "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."
Flash has had the same problems (Score:5, Insightful)
Re:Flash has had the same problems (Score:4, Informative)
With Flash I doubt that the features added between Version 8 and Version 10 were natural progressions and refinements of the concepts and principles on which that system is based. Instead, I see them as "we gotta give our customers a reason to buy the latest version so let's add more bloat!"
It depends on how sound and useful the initial design was. The POSIX standard has a slow development cycle. So does the X Windowing Protocol. I haven't seen many fundamental innovations for the TCP protocol lately either. I have seen bugfixes and things of that nature, but not much bloat and feature creep. For those things, the design closely matched the intended purpose and philosophy and there was little or no marketing pressure to always have something new to sell. I think it's precisely because those things are the concern of geeks and are the "under the hood" type of thing that average end-users wouldn't directly work with. Things like Flash animations and iPhones are much more visible and immediately practical for average users and there we see marketing pressures and faster developments.
I think what Adobe has realized is that the proposed video functions of HTML5 could be a direct threat to their little proprietary standard fiefdom and that vendors like Apple have some good (business) reasons not to use their products. I think that would get them to concentrate on something more substantial than more bells and whistles and put pressure on them to produce a good, solid runtime. The only thing I wonder is whether they are prepared to address the absolute joke that Flash has been when it comes to security. It's easily up there with Sendmail and BIND so far as track records are concerned.
I hope so. The closed nature of Apple's products is my biggest single problem with them. Most users don't care so there is little reason for Apple to see this as a problem. Therefore, what it would take to change that would be another company (like Google) who can give them serious competition without such tactics.
Conscious or subconscious, that looks to me like what you realize is that some Slashdotters love to attack you based on things you never actually claimed. Had you omitted that line, I could see them now, the follow-up posts saying "huh huh, an OS is not a runtime, therefore you don't know what you're talking about and you're wrong and I'm right so hah!" The way I explain it is that if I didn't explicitly outright claim something, it's for a reason and is not the product of random chance.
My approach to those would-be killjoys for whom feeling superior to somebody is more important than reading comprehension is different. I refuse to add little disclaimers like that because for more nuanced posts, those would be longer than the point I am making. I also refuse to do it because I won't cater to maladaptive behavior that disguises itself as useful critique. Instead, I let them try that on me and then show them why it was useless.
Re: (Score:2)
The POSIX standard has a slow development cycle. So does the X Windowing Protocol.
The X Windowing Protocol went through 11 incompatible versions in its first three-and-a-half years. So by comparison, Android is downright stodgy.
Re: (Score:2)
The POSIX standard has a slow development cycle. So does the X Windowing Protocol.
The X Windowing Protocol went through 11 incompatible versions in its first three-and-a-half years. So by comparison, Android is downright stodgy.
Not to be nit-picky but this situation calls for it: saying it "has" (present tense) a slow development cycle is not a claim that this has always been the case since its inception.
Re: (Score:2)
Not to be nit-picky but this situation calls for it: saying it "has" (present tense) a slow development cycle is not a claim that this has always been the case since its inception.
You think the situation calls for being nit-picky? Wonderful, sir. Then let us pick the nit in context:
It depends on how sound and useful the initial design was. The POSIX standard has a slow development cycle. So does the X Windowing Protocol.
Saying that "[i]t depends on how sound and useful the initial design was" is an explicit invocation of the case at the inception. And so the state of your examples at their respective inceptions is plainly relevant to evaluating your statement.
Re: (Score:2)
Not to be nit-picky but this situation calls for it: saying it "has" (present tense) a slow development cycle is not a claim that this has always been the case since its inception.
You think the situation calls for being nit-picky? Wonderful, sir. Then let us pick the nit in context:
It depends on how sound and useful the initial design was. The POSIX standard has a slow development cycle. So does the X Windowing Protocol.
Saying that "[i]t depends on how sound and useful the initial design was" is an explicit invocation of the case at the inception. And so the state of your examples at their respective inceptions is plainly relevant to evaluating your statement.
First of all, the X protocol of which I spoke has been around since Project Athena (MIT) in 1984. That's about 26 years. The first 3 years of those 26 years constitutes 11.5% of its history and only the earliest part thereof. The point you think you are making hinges on a small minority of its overall history that has nothing to do with the present-day case of which I explicitly spoke.
You failed to properly understand the last two paragraphs of my initial post in this thread, where I said that the way
Re: (Score:2)
I would have to agree, though I wouldn't have stated it so aggressively.
Yes, the competition is the one spearheading this talking point. I wrote in an earlier post that it might be justified to fire the editor for ruining the career of the journalist by allowing this sort of article to be published. Maybe the journalists that are serious about their careers should look harder before agreeing to write such crap.
Android 2.2 helping with this? (Score:2)
I think if handset makers and carriers can do this, getting Android 2.2 as a baseline onto all devices might be what the doctor ordered for this.
The main reason is not just JIT compiling, nor the ability to run apps on the SD card (which is important for older phones). Instead, Android 2.2 offers a lot more modular upgrade path, where before devices in previous versions would have to be completely reflashed just to support one item.
Time will tell if 2.2 gets adopted, or if we still have the version fragmen
Re: (Score:2)
That works for the geeks, but the casual user is going to get frustrated that he has to buy a new phone to get all of the things that his friends get merely by updating. HTC makes some excellent phones, but their business model is based on a significant portion of their users buying phones more rapidly than every two years.
Words of Wisdom (Score:4, Insightful)
With apologies to... Henry Spencer [wikipedia.org]:
"Those who fail to understand apt-get are condemned to re-invent it, poorly."
Re: (Score:2)
Someone want to explain to me what makes this "Interesting?" Or for that matter, what makes it at all relevant...
Re:Words of Wisdom (Score:5, Informative)
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.
Re:Words of Wisdom (Score:4, Insightful)
It's not likely to happen because apt-get is a pretty terrible model for end-user facing software.
The Android software distribution and versioning model is pretty much exactly what I spent a couple of years campaigning for in the desktop Linux world about 5-6 years ago. Some of the core ideas of apt are there - a central repository of software that vends package files which can be obtained via other means if you want.
But Android nails so many things the desktop Linux guys just never understood. For one, apps depend on the platform and nothing else. Some apps can gain additional functionality when other apps are present and the OS makes that easy to code up, but those dependencies are always optional. The market doesn't have any concept of "dependency resolution" because otherwise you'd rapidly end up with what you get in the Linux world - uninstallable applications with no good way to explain why to the end user.
The Android model allows software dependencies on a strongly versioned platform, and also allows hardware dependencies because they do vary by device (I'll note that apt has no concept of a hardware dependency). The versioning of the Android platform is "correct" in that it's what I always wanted Linux to move to - a single number that identifies a large range of APIs that are revved together every so often. GNOME follows this model most closely in the Linux world. But GNOME misses some key pieces. Firstly the Android dev tools make it easy to target old versions, so easy it's actually the default. Now try compiling an app on your up to date developer workstation that targets GNOME 2.0 - you'll find it's not possible. The development tools will conspire to stop you (typically header files). I complained about this several times and was told, basically, that there was no interest in fixing this.
It's unsurprising then that the Linux model has collapsed into chaos so quickly, a chaos so profound that the only way to tackle it is to try and "stop the world" every 6 months. People might bitch about Android fragmentation today, but they'd bitch a lot more if only one version of their app was offered to each user, tied to OS upgrades!
That depends, really... (Score:5, Insightful)
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.
Consumers don't care. Developers get a bum deal (Score:4, Insightful)
My Droid Eris was on Android 1.5 for the last several months and I noticed very few differences between it and my father's Droid with 2.0. Yea he had voice nav, and he got live wallpapers when the 2.1 rolled out, but the core features that made me love the OS were largely identical (push gmail, widgets, great web browsing experience, etc.).
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.
Re: (Score:2)
So it's a real problem to some big-time apps. This may also limit how many apps become big-time apps.
Re:Consumers don't care. Developers get a bum deal (Score:5, Interesting)
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.
Re: (Score:2)
I would have thought that the last 20 years of desktop OS programming would have taught programmers how to deal with the fact that not every customer has an identical piece of hardware. I'm sure it makes it marginally harder when you aren't programming for a completely homogeneous platform, but it's not a new paradigm.
This isn't Google's fault... (Score:5, Insightful)
Re: (Score:2)
It is not that simple.
As just one example, ROM modders are willing to put up with "brick rates" that would result in class action suits if a device manufacturer and carrier tried the same thing. A 99% success rate -- which a ROM modde
Re: (Score:2)
There is no "properly" in some cases, for an upgrade to be sufficiently reliable.
iPhone fragmentation (Score:5, Insightful)
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.
Re: (Score:2, Flamebait)
"you have to buy the OS upgrades, which I haven't bothered to do"
$5 is that tough to part with?
Re: (Score:2)
Exactly. iPhone upgrades have always been free, so developers only need to target the current major version. iTunes prompts for upgrades whenever one is released, so it would be nonsensical to run an old OS. For iTouches, if someone won't pay for a $5-$10 (I think they are $10) upgrade every six months or so, then as a developer, why should I care about them? If my app is free, then there is no expectation that I spend extra work supporting legacy systems, and if it costs money, then why do I care about the
Re:iPhone fragmentation (Score:4, Informative)
With an iPod Touch you have to buy the OS upgrades, which I haven't bothered to do.
Not if you know where to download the appropriate ipsw file (from Apple's own CDN servers no less!). Google is your friend here.
Re: (Score:3, Insightful)
You really like to repeat this story - this is at least the fifth time I've read it. You also illustrate zero knowledge of the platform, which makes me believe you are just here to lay down some astroturf.
Re: (Score:3, Insightful)
I do the final QA and Management sign off before a product is delivered to a customer. I keep an eye on the number of support tickets filed for various platforms & products so I know roughly what to budget. I can tell you the number of ticket reports filed for interpretability problems on Android is over 8 to 1 compared to the iPhone. To be fair the Blackberry has similar QA costs to Android.
Re: (Score:2, Insightful)
- A G1 (your basic android device)
- A Nexus One (high res screen and latest firmware)
- A Droid/Milestone (to cover the Ti processor)
- A Samsung Galaxy Should come to less than 2500 easily.
Andy Rubin's Bullshit (Score:3, Insightful)
"Andy's point was simple. Older Android devices that can't be upgraded to newer versions of the OS or run newer apps are no different than an iPhone from 2007 not being updated to OS 4."
Rubin obfuscates the problem by trying to simplify things, which is working. The issues:
* my android device can't be upgraded
* my android app don't work on x version of android
* my android app doesn't work on y version of hardware
iPhone 4.0 is irrelevant, since it doesn't exist yet. And it is not like iPhone 3Gs not moving to iPhone 4. It's more like an app on an iPhone 3G with iPhone OS 2.0 can't run iPhone OS 3.0 because (a) the device itself can't be upgraded to iPhone OS 3.0, and/or (2) because iPhone OS 3.0 isn't backwards-compatible with iPhone OS 2.0.
I have plenty of iPhone apps that were first-generation that still work. That sounds like an unlikely situation in the android world. I also have apps that work on all versions of OS and hardware. I have a few that require specific features (GPS) that don't exist on 1.0 hardware...so obviously don't work on newer devices. I had a few apps (WiFi scanners) that died under OS 3.0 that used to work.
It sounds, however, that compatibility across android and handset versions is not only not guaranteed with android, but that the incompatibility is to be expected...according to their chief architect.
Nice.
Re: (Score:2)
Re: (Score:2)
* my android device can't be upgraded
* my android app don't work on x version of android
* my android app doesn't work on y version of hardware
Interestingly, if Android were something like... say GPLv3, so that end users could update the OS, and if you had a compelling enough app, I think that you could then get people to upgrade their phone OS in order to run the new versions of your application.
Certain issues, for example lack of an accelerometer or a GPS unit, are insurmountable. You'll just have to suck it up and deal with those hardware revs in your builds, or indicate that you're not officially supporting that hardware anymore.
It sounds, however, that compatibility across android and handset versions is not only not guaranteed with android, but that the incompatibility is to be expected...according to their chief architect.
Nice.
Android isn't
Did you actually *read* the article? (Score:3, Informative)
Silly question I know, but reading your post just makes its title look all the more ironic.
Hardware and legacy-OS "fragmentation" exists today in the iPhone ecosystem - nearly half [ilounge.com] of iPod Touches are running older systems, and there are already iPhone owners who will never be able to upgrade to OS 4 (even the beta). It's obviously greater in Android due to the larger choice of hardware and more rapid OS releases. Some may prefer a slower-moving target, but the monolithic, our-way-or-the-highway approach th
somewhat misleading (Score:4, Informative)
Of the '5' versions, only 3 have anything resembling significant usage in the wild (1.5, 1.6 and 2.1). Multiple phones have had 2.1 upgrades released for them since the statistics were gathered, thus throwing even those statistics out of whack. Once all the handsets that are capable of running 2.2 are upgraded, I think that will be a pretty stable platform for quite some time - most everything that people have been clamoring for in Android is either in or supported by, that version (Flash, App2SD, bluetooth voice calling, JIT, etc). Many of the handsets that are older and 1.5/1.6-based might not perform all that well with these new features (if at all) due to constrained physical resources (slower CPU, less RAM, etc).
Coming out with new hardware now with anything less than 2.1 should be a crime, though. I'm glad they've said the EVO 4G will have a 2.2 upgrade in July. *whew*
Just give us our devices rooted (Score:2)
I mean, seriously? What do they have to lose for giving us pre-rooted phones?
Re: (Score:2, Interesting)
Control. If they give up that, they might not be able to force you on to their services.
Motorola's the worst, since they sign the bootloader, kernel, and file system. The devices won't boot if any part of that has changed, and the only device you -can- change is the DROID (though the Milestone variant is locked down, last I checked.)
Re: (Score:2)
phone manufacturers don't care. service providers do.
they have an interest in being able to control the software that runs on devices that connect to their network. the most obvious example is tethering. they don't want everyone to have it for free, they want to charge $30 / month extra. on a rooted phone they can't control that.
so yes, they have a lot to lose.
Re: (Score:2)
AT&T, Verizon, T-Mobile and Sprint all have a lot to gamble on with their phones. If they gave us our devices pre-rooted, it would come down to price and performance. No one is going to jump ship from Verizon, Sprint or T-Mobile to get AT&T's Android phones because they are so #$@#$ awful. If they all allowed rooting, the Backflip might not be the complete crapfest of bloatware and stupid design decisions (seriously, no non-market apps, no Google search, non-removable crapwa
Re: (Score:2)
I'm seriously considering jumping from ATT to Verizon due to the lack of ATT support for any halfway decent Android device.
I currently have a winmo device with ATT and while I'm sort of happy with it, Windows Mobile just isn't meant for a mobile device. That sounds like an incredibly stupid statement, but without tweaks etc it is truly a horrible phone.
App compatibility. (Score:2)
Why this story was posted (Score:2)
Apple zealots are getting nervous about Android so this story seeks to reassure them that the rapid improvement of Android is a bad thing.
Re: (Score:2)
Ok, moronic comment aside, this is a problem.
And, I want to into Android development, but new and better phones keep coming out. The droid was the first one I thought about getting, then Google released the Nexus one. But the Nexus one has a weird screen ( 2x green pixels to each red + blue), so I worried about that. Now there is the Evo, a newer phone. Plus, I worry about getting stuck with the g1's memory issue, where it can not take the newer OS version. Plus, I have to worry about motorola or HTC releas
Re: (Score:3, Insightful)
Dude, we code in Java targeting a virtual machine (it's called Dalvic). You don't worry about the hardware underneath - Android's APIs and virtual machine takes care of all of that stuff for you. You don't even have to have an Android device to do development. The SDK comes with an emulator that lets you build and test your apps on Windows, Linux or MacOS.
Now that we've cleared that up, head over to the Android site and download the SDK and learn to write an app instead of worrying about phone hardware. Th
Re: (Score:3, Informative)
The default for an Android developer should be the N1. The "weird screen" isn't a factor in practice, there still aren't any other phones with significantly better specs, and it's virtually guaranteed to get timely updates for the next few years because there are no incompetent and/or malicious middlemen.
24 million "enemy" devices sold already (Score:2)
You know the real interesting thing which is fortunate for some companies is: People ignoring numbers like 24 million, in first 6 months of 2010. That is Symbian, supposed to be "fragmented" while single sisx file installs to almost anything.
You know what could drive all of them to real panic? If Nokia gets the neat idea of shipping a fully supported (and of course, working) Qt SDK for Android.
While on it, a device very similar to Android sold 19 million too... Blackberry... If you add them, it makes 43 mil
Terrible Summary (Score:2)
I believe this development cycle could turn casual consumers away and hurt Android's chances at long term mainstream success.
Sounds like the submitter is suggesting we artificially slow the rate of innovation. Hey, maybe we should just not release new devices with new features at all. That way no one will feel left out!
They say the same thing about Symbian/J2ME (Score:3, Interesting)
This is going on for years on Symbian scene and J2ME (Java Micro), same thing being said over and over and unfortunately some developers seem to actually believe it.
I will give one single title: Opera. Opera Mobile runs on ANY Symbian S60 and Opera Mini runs on ANY J2ME client. There is no "Opera Mobile for Nokia E71", the drop down menus on some download may confuse you. It is just, some developers, especially the ones directly selling (no trial) apps want to make sure the application will run instead of living hassle to give money back or bad feedback. Another thing is, root certs which devices have. Some have Verisign, some hove Thawte or both. They want to make sure (especially with J2ME) that application won't be treated as "unsigned", especially network aware apps.
Of course, if you see something like "S60 V3 FP2", it may confuse you. It just says "Devices with compass built in", much like iPhone 3G vs 3GS and I don't see anyone talking about fragmentation on iPhone scene.
So J2ME is really "write once,run anywhere" and Symbian is really device independent. Of course, the Developer makes the difference.
Re: (Score:2)
Do they really? I upgraded my phone only about a year and a half ago. That phone's no longer available at all through my carrier. You can't even get a refurbished one. And when I got it it'd been available for less than 6 months. So, less than 2 years from initial release to completely obsolete and unavailable.
I think customers expect their phone to function for the full length of the contract, but I don't think anybody expects it to actually be current for more than a year anymore. And I think the carriers