One of the things that makes Mobile development interesting to me is the mobile context, unlike the static context of desktop computing. But being smart in the mobile context requires using sensors, and this hardware boundary is where we see a lot of behavioral differences among Android phones (fragmentation). The existing CTS doesn't do a good enough job here. Its where the fragmentation is the worst - in the interesting APIs.
Also, the fragmentation problem for me is also about Google being able to deliver features to users at a reasonable speed. They can with the Nexus, but the Nexus was and is not likely to ever be a commercial success. Its mainly HW for the Google engineers to dev on, and they make a few more for us.
Bluetooth low energy was announced in 4.3. How long will it take for that feature to arrive for a sizable number of users?
What about the limitations of dvm? For example, its 65k method limit for APKs. How can Google fix this when they can't get everybody on the same page in a reasonable amount of time? Its this kind of fragmentation that hurts.
If you're building some basic CRUD app, don't worry. If you want to make interesting nontrivial apps that touch many APIS - especially HW APIS, that when you have to watch out - and have a very good testing plan.
* Samsung S3/Note2 - requestSingleLocationUpdate() would never return a location to the listener, where starting the location listener and then stopping it when you get your first result works fine...
* Samsung S3 (4.0.4) - onResume() then onPause() was being called repeatedly after the device blanked the screen (the time varies before it starts freaking out and calling onResume) - I observed it wait 7 minutes, then start calling onResume/onPause a few times per minute.
edit: formatting
though "Close to working" is as good as I can say for my wife's Note2... it was extremely flakey and loses connection all the time.
I'm seeing a lot of apps that assume too much. They assume I've got GPS. And even if I had GPS they assume it is turned on. Same for Wifi or any data connection. Therefore a lot of crashes occur because of null pointer exceptions.
The simple fix is ofcourse to null check or to use a little more of try and catch.
Specifically, most apps should be able to perform their functions off-line. Why? Because mobile data is expensive and unpredictable in a lot of countries. You can't expect that 3G will be on and working, and you can't expect that someone will be inside wifi.
FWIW, anecdata and all that, the majority of people I know in NZ prepay for data in chunks that roll over multiple months, and so they only turn on 3G when absolutely necessary.
In fact, the current Xcode version only enables developers to target iOS 4.3 and above. So even if a developer would want to support 3.0, he would not be able to do so.
By comparison 2.5% of the android userbase was still on 2.2[0]. Though things look good as it's been falling fast (2.2 was over 8% in february)
[0] http://www.gsmarena.com/android_in_july_41_jb_now_more_popul...
It's a high percentage, but mainly because of negative selection. People who don't care about apps bought cheapest Android phones.
After a couple questions I realized that she couldn't figure out which ones were the iPhones from the Android from the Windows Phone. So I walked around with her to the phones that she liked and answered a few questions about each (storage, battery, if it was a popular phone that sort of thing). I realized that she hadn't even checked out the iPhones at all. They were kept over in a special Apple section of the store, and from a distance looked like the small budget smart phones they had elsewhere in the store. So she had skipped them entirely. All of the phones she liked were in the larger screen sizes.
I took her over to them and the conversation went something like this, "and these are the famous iPhones, give them a try, they're really easy to use." She messed with it a bit, "isn't there a bigger one, like the other phones?" I pointed out that it's designed to be easier to use in one hand, for people on the go. "But it's so small, it's hard to see things on the screen, I have to hold it so close" She pointed to the iPad mini they had there "something in-between that one and this one"
And that was that, it came down to a decision between the Droid MAXX, the Galaxy S4 and the Galaxy Note II. She walked out with an S4.
One girl I knew was complaining about how big her phone is and asked me about my 4s at the time so I let her try it out. She decided she'd get the 5 right after it was out because her current phone was "too damn big to text with easily". I pointed out she could install a different launcher/keyboard but her phone had never been updated.
This is the problem with anecdotes. The plural is not data.
I also know a fair amount of women primarily that have iphones because they don't like the giant android phones. But again, could just be my friends, where I live, the alignments of whatever influencing buying decisions.
I'm getting more annoyed with all of these "my anecdote X which reinforces view Y means company FOO should BLAH" comments. They don't really contribute to actual discussion of the technical problems at hand, which are interesting. Hopefully that didn't come off too harsh as its just intended to spark more of a discussion of can we please stop with anecdotes in these stories in future? Pretty please? If you come to the twin cities I'll even buy you beer, or if we're ever in the same spot. I'm not above bribing.
I have a republic wireless android phone that ships with very little free memory until you root it. Have to be Very careful and pick and choose which apps you install based on size. Is it worth uninstalling evernote to fit this new app? Or is your new app worth the $100/month it would cost to switch to a carrier with a more advanced phone where space wouldn't matter?
I also have a 32 gig nexus7 tablet where I pretty much don't have to care about app size. 500 meg game, well OK whatever.
The article advises fooling around with different UI depending on device size. Users actually hate that. I can't stand how baconreader renders differently on my phone and on my tablet, when they should be the same. gmail is another offender. I want the phone gmail on my tablet and the tablet baconreader on my phone (or was it the other way around?) Users can understand screen and finger size issues but can't tolerate arbitrary foolin around with UI design.
They are two different things, with their own problems,so it is better to try to be precise.
I have enough ram not to be ram limited, but for example per my "running" tab, tunein radio pro burns up about 20 megs continuously. No idea why and I don't think I'm getting 20 megs worth of battery draining "anything" out of it. Too bad, because when I'm actually using it, its an awesome app. Google Goggles burns a bit less than 6 megs continuously, even if you're not using it, to do... what exactly?
This all costs battery, if nothing else. I'd rather have an extra hour of runtime rather than goggles and tunein starting up slightly faster when I use them.
There should be a configurable android setting where "piggish" apps can ask to start a battery sucking and ram sucking 24x7x365 service, but this specific app is simply not allowed to do so because its a pig-app.
"While Android fragmentation is increasing, the development time for developers is not."
Because earlier in the article it states this:
"Whenever we have a new release we spend about four hours testing the new build on all the devices. In total we estimate the extra effort of fixing device or vendor specific crashes to add 10% to our development time."
So it seems a bit inconsistent. If there is more fragmentation, then that 10% development time figure would necessarily have to increase.
I would be interested in the data demonstrating the cost-benefit analysis of supporting the high fragmentation as opposed to just supporting the the OS version with the highest penetration. I'm not arguing either way, but it would be interesting to see the effect on revenue. My hypothesis is that older OSes would likely result in less revenue (than newer OSes), so the question would be if the revenue would exceed the percentage of development cost dedicated to the particular OS in question. I really have no idea.
Oh, $app? I heard about $app but it didn't support my phone on launch day, so I ignored them and installed a competitor who works everywhere. Oh, $app added support for my phone 6 months ago? Who cares, I've had $competitor installed for 7 months.
4.0.X is Ice Cream Sandwich, not Jelly Bean.
I think they're all supposed to be desserts. Akin to how all releases of OSX have cat names. Until the last one. Combo breaker!
The challenge is of course backporting an app developed for 4.0 or frontporting an old app in the new API. That is definitely a pain.
