Angry Birds maker apologizes for Android fragmentation issues
appleinsider.com
appleinsider.com
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.)
Clearly you have not had the wonderful experience of trying to get something working in IE the way it works in all the other browsers!
And this solves the problems of users not having it how?
That should handle it.
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 web example would be getElementsByClassName:
function getElementsByClassName(node,classname) {
if (node.getElementsByClassName)
return node.getElementsByClassName(classname);
else {
// your custom function
}
}
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.
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.
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 :)
http://news.ycombinator.com/item?id=1917559
To be fair, my example sucked and I totally did misunderstand the Netflix issue. But I was right on the basic fragmentation problem, dagnabbit! =)
Really? I think it's common to consider the PC market to be fragmented, especially when it comes to complex software like games.
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.
Um, that's the definition of fragmentation.