Incidentally, the web has failed because there are 5 different major browsers, and personal computers have failed, because there is an infinite combination of available hardware.
How could anyone have tested on all those? How could anyone have ever developed a working web application? How could anyone have ever developed a working Windows application?
The non-sarcastic answer: most of the time, the differences are irrelevant. The rest of the time, you need to build an abstraction, and then the second case becomes the first! Forever!
(Android is open-source. If you need a function that only Android 2.2 has, backport it to 1.6! If you need an abstraction layer for dealing with 24-bit or 16-bit screens, write one and share it with the world! Android is open, and you have to exploit that fact to be successful. You can't go off into your own little Universe where there is one person with one phone running one app at a time. That may be the iOS strategy, but it's not what works for Android.)
Tell that to the people that have wasted thousands upon thousands of man-hours because of IE. Surely if the history of IE had been written differently the web would probably be a few years ahead of where we are at right now.
Well obviously you just need to backport it to 1.6, update all the custom user interfaces that each of the device makers have made, hack into several different OTA update systems, and force an update for millions of devices. Piece of cake right?
I could be incorrect, but I think he means implement the feature on top of 1.6, not the system itself.
The web example would be getElementsByClassName:
function getElementsByClassName(node,classname) {
if (node.getElementsByClassName)
return node.getElementsByClassName(classname);
else {
// your custom function
}
}
Compare this with the "lol" sub-thread of mockery, sibling to this. Online technical communities die when the incompetent substitute jokes for thought, in their haste to say something.
I'm sorry but he said to "backport it to 1.6" which would mean taking code from a more advanced version and making it work on an older codebase. This would involve updates to the 1.6 release or forking, which is what the other two "lol" comments in the thread are making fun of. If he would have said "re-implement it in your own app" I wouldn't have asked the question, and regardless, there's no need for the personal insults.
A small part of ever community dies any time some random fanboy resorts to ad hominems.
I'm sorry but he said to "backport it to 1.6" which would mean taking code from a more advanced version and making it work on an older codebase.
Out of a few possible meanings, you chose the most baroque.
When writing portable code, you have a few approaches:
1) Target least-common denominator, and enable advanced features on richer targets ("Graceful Degradation").
2) Target one platform/version maximally, and bundle your own abstraction layer for incompatible targets (Cygwin.)
3) Create your entire application in an environment created solely from a few, universally available primitives (a la Java Swing) or create your own ultra-portable runtime (java itself, Flash.)
4) Co-bundle a bunch of versions of the app for disparate platforms into one container format (Mac fat-binaries) -- this is the ugliest form of portability, almost analogous to ad-hoc polymorphism.
5) There are also self-improving systems that boot off simple stub code, and load more functionality from remote hosts, possibly compiling themselves on the new host, possibly using partial-evaluation and specialization, etc.
As a programmer, your first instinct for making a piece of code portable should be along these lines. The idea of patching the world to accommodate your needs should never cross your mind.
I would have loved to make this discussion about Android portability strategies. I mean, if MS-DOS 5 and 6.22 were binary compatible for device drivers, even though they used completely different device "models", then I am sure we can bump heads and exchange tricks for Android, iOS and other mobile OSes that are about to shatter like champagne glass on tarmac.
It's customary in software engineering to "wrap" and augment system infrastructure with your own portability layer. You can see this everywhere; the Linux kernel, for example, bundles its own little library for emulating floating-point processing, for x86 systems that don't have x87 (very rare!).
The whole point of the C compiler -D argument is to allow you to enable features at compile time. GNU Autotools exploit this by inspecting the host environment and enumerating the available "features", allowing the build scripts to selectively compile your portability layers when a feature is missing.
With Android, you can use runtime reflection to instantiate the right objects, based on system parameters. I.e. your compiled APK can behave differently on two systems, say, by enabling extra functionality on older OS versions.
The problem isn't 'fragmentation'. The problem is that some hardware can't handle the way they wrote the code. They are going to write a version that uses less processor power and release that as well.
If they had written the 'lighter' version first, it would run on all devices.
Nobody ever talks about the PC market being fragmented, and yet it's nothing but fragments. It's difficult to find 2 PCs that are identical unless they were purchased at the same time. That doesn't stop developers from making apps and games for PCs.
When they say that 'fragmentation' prevented them from reaching the whole market, what they're really saying is that their software uses too much CPU or another resource.
Android is a like a whole new ball game when it comes to fragmentation.
You can't rely on the same kind of touch screens, or a keyboard being present, or a trackball, or the speed being same, or an SD card existing, and the screen sizes all seem to be so different, cutting off part of your game's graphics or touch-areas.
On a PC, I can count on there being a 2 button mouse, keyboard, and a 1024x768 resolution in a pinch. There seems to be no fall-back on Android.
Then to top it off, it results in angry user feedback.
And what frustrates ME the most ... comments in the Android Market don't even tell us what phone model the poster is using. For goodness sake, the number of problems this would solve is HUGE.
OK ok, I'm beginning to rant. All I'm saying is Android is in a fragmentation class of its own :)
The XBox was born of the fact that it used to be an incredible pain in the neck to get PC games running on your custom hardware. That and the fact that custom hardware evolved so quickly that programmers could barely target a given class of GPU before it was obsolete.
Uh, hmm, y'know considering that the XBox was a single core clocked at 733mhz with 512mb of shared RAM at a time when your average gaming PC was packing approximately twice ghat power plus a discrete graphics card, I can't help but think that the fact that the developers knew the exact performance characteristics of the machine made it a lot easier to wrench a lot of power out of it.
Also, it stuck around for at least 4 years.
There has got to be something to the fact that they didn't stick with an x86 architecture for the next revision as well.
How could anyone have tested on all those? How could anyone have ever developed a working web application? How could anyone have ever developed a working Windows application?
The non-sarcastic answer: most of the time, the differences are irrelevant. The rest of the time, you need to build an abstraction, and then the second case becomes the first! Forever!
(Android is open-source. If you need a function that only Android 2.2 has, backport it to 1.6! If you need an abstraction layer for dealing with 24-bit or 16-bit screens, write one and share it with the world! Android is open, and you have to exploit that fact to be successful. You can't go off into your own little Universe where there is one person with one phone running one app at a time. That may be the iOS strategy, but it's not what works for Android.)