> If you need a function that only Android 2.2 has, backport it to 1.6!
And this solves the problems of users not having it how?
And this solves the problems of users not having it how?
That should handle it.
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.
A small part of ever community dies any time some random fanboy resorts to ad hominems.
:)
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.
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.