|
|
|
|
|
|
by georgemcbay
4470 days ago
|
|
|
It is both a real thing and laziness. With decent technical design and Google's Android support library you can pretty much code as if 98% of people run KitKat and not worry about it, the support library will fallback gracefully down to all the OS versions you do care about. Most of the time when I hear designers complaining about Android fragmentation they are really just using "fragmentation" as a scapegoat to bemoan they fact that they can't just create a very small set (1-3) of universal "pixel perfect" mockups and ship those off as a PSD to a developer as the end-all, be-all "visual spec". They have to worry about things like how different parts of the app should scale as more real estate is made available, really understand DPI (I've met more than a few designers who shockingly don't really grasp DPI scaling), etc. Some designers are awesome at this and welcome the challenges (and benefits!) that "responsive layout" brings with it, but a lot of them (most of them, in my personal experience) just want to punt on all that shit. |
|
|
People say this. It's not really actually true.
A nice little example encountered recently. Say you have a HTTP server which uses gzip or deflate when the client asks it to. Pretty standard, right? And say you want to return a HTTP 204, or other contentless success. Seems reasonable? And if you do this on Android 4.4 using the standard HTTP client, it will work. If you do it on Android 4.1 (the most commonly-deployed version of Android), it will throw a null pointer exception deep in the library code.
This is just one of many issues. Compatibility support libraries are all very well, but they don't really help with the standard libraries being buggy, and those bugs will _never be fixed_ for the vast majority of users.
It gets even worse when you take OEM crap into account. Want to use the camera? You'd better know about obscure Samsung quirks: http://stackoverflow.com/questions/13448731/does-samsung-gal...