For Android Users, 2012 Is Still the Year of Gingerbread 257
First time accepted submitter brocket66 writes with this excerpt from BGR: "Three major revisions of Google's Android operating system have launched since the company released Android 2.3 more than 21 months ago in December 2010, but Gingerbread is still the most widely used version of Android by a wide margin. A study conducted early this year by graphic designer Chris Sauve projected that based on Android adoption trends up to that point, Android 2.3 Gingerbread would be the dominant version of Android in 2012 despite the fact that Android 3.0 Honeycomb and Android 4.0 Ice Cream Sandwich had already been released. Now, as the fourth quarter of 2012 approaches, data from Google's Android version distribution tracker confirms once again that those projections were accurate."
So? (Score:5, Interesting)
android 3.0 (Score:3, Interesting)
What are the min requirements for Jelly Bean? (Score:4, Interesting)
I've been assuming the reason there are lots of 1.x and 2.x phones out there just had to do with the fact there are a lot of low-end Android phones for sale. I figured ICS and JB had fairly stiff hardware requirements. Is that not correct?
May I say... (Score:2, Interesting)
Re:So? (Score:4, Interesting)
Oh please. It's the developer's fault that most people don't want to spend $500 for a phone?
Re:So? (Score:3, Interesting)
1)Too many versions too quickly.
Thus is life in the mobile world...
2)Not enough work on backwards compatibility. If I use the 4.0 features, there's no good fallback. Java doesn't help them here- in C++ I could #define in 2.x and 4.x blocks, Java requires lots of reflection aware code because there is no conditional compilation. Or you need to set up special stuff with antenna and the like, which is hard to get working nicely with all the tools.
This is something I have far too much experience with from the world of BlackBerry. I've done both preprocessor hacks (which is supported by the build tools, but Eclipse hates), and fancy crap with libraries/pseudo-reflection/design-patterns (which lesser developers might cringe at figuring out). Either way, its not fun. It basically means that you have to use any new features "by exception", versus "by design", which makes it very hard to fully leverage them if the intent is to make your life as a developer better.
3)The ratio is still out of whack with more 2.x phones sold than 4.0. This is due to so few phones being upgradeable
Or due to carriers not bothering to push updates, when the vendors have. Or due to users not knowing/caring that they should upgrade. Or due to people clinging to their ancient phones and developers having a hard time justifying cutting them off if they want to maximize adoption. Regardless, having so many players between "OS upstream source" and "end user's device", you're pretty much doomed to this problem.
4)For whatever reason, I don't see a lot of open source stepping in to help this. On the PC, there's be open source libraries galore to step into the gap. On mobiles, not so much. I think the idea of easy monetization via ads (regardless of how much you actually make) has helped to kill the open source movement on mobile phones. Plenty of free help out there, but not much in the way of quality libraries. But these are the people who generally would be jumping on new features. Without them, its mostly commercial devs and they just want to target the mass market.
On the PC, you also have continual upgrades to common libraries separate from the whole OS, and sometimes even multiple versions of libraries installed. Additionally, the upgrade cycles of the hardware are almost completely separated from the upgrade cycles of these libraries. (at least in relation to the time scales we're talking about)
I also agree that the mobile business models have greatly discouraged open source. Its quite frustrating, too, since it places far more burden on the shoulders of the platform vendor to provide everything. There's also this idea that you're supposed to try and make money off any and every mobile project. Regardless of how likely you are to actually succeed, you're looked down upon if you don't at least try. And often trying, means your effort isn't going to be open source at all. (Personally, I'd rather make something open-source and gain the community benefits than try to make an insignificant pittance off it as closed-source. If I'm closing something down, its because the monetary benefit is real and not imagined.)
Re:So? (Score:5, Interesting)
And sadly, I don't think that the platform vendor is keeping up. I've recently started heavily writing my own reusable components, with the idea of spitting out a lot of small easy apps (to try and force myself to think in those terms, since I usually dream up giant multi-month efforts). Some of the things I had to write myself were ridiculously common, yet every damn dev is writing their own.
*Splash screen (and side note: the tutorials I found on the web on how to make one were all horrible, involving spawning threads and making sleep calls).
*Intents to just play full screen video, or audio and matching image.
*An Image widget that can use a resource or a URL as the source.
*A wrapper around their gyroscope and accelerometer to form a compass sensor. Something they used to have (ORIENTATION_SENSOR) then deprecated.
*A single function call method to get a URL as a string (or as an image, etc).
*A view that displays the output of the camera, and manages requesting access to the camera when the activity is paused/unpaused. Really, how the hell did they miss this?
*A JSON parsing library that will take JSON and an object definition and use reflection to turn the JSON into a java object.
Really, most of these are extremely common. Most aren't that hard, only the compass took significant time, and that because I needed to figure out the linear algebra and then clean up the sensor data. But google isn't providing it, and there aren't any good common Android libraries so everyone is rewriting most of these. And sure, some of these have limited use, but there's still ridiculous amounts of time being wasted by rewriting these thousands of times. Give us better tools to get out jobs done quickly, and we might have time to play with more advanced features.