4 ms·
> 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?
by mishmash 16y ago
> 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?
- fletchowns 16y agoWell 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?
- jrockway 16y agoYou ship it with your app. When the users get your app, they get your abstraction layer.
- mahmud 16y agoThank you. The sensible answer of an engineer. 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.
- mishmash 16y agoI'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. :)
- mahmud 16y agoI'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.
- nym 16y agoI 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 } } (example from quirksmode.org)
- mahmud 16y agoIt'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.