This is better than nothing, and I suppose it's far too late to do anything else, but I was really hoping they'd force manufacturers to provide updates and unify the platform a little.
If you have to test on all the devices and make individual builds for different devices, development sucks. I was at Loopt when we supported J2ME, where every phone that was supposed to be the same[1] was different, and per-device builds were the only solution. It was a nightmare. In the long term, I fear Android won't be much better in that regard.
[1] Java runs the same everywhere! All the JREs are validated by Sun and pass the same tests!
Even if they force manufacturers to provide updates, that doesn't completely solve the problem. Just look at how many iOS devices are on older releases just because users have never plugged them into their computers to get updates. And just because Android allows carriers to push updates OTA doesn't mean users will actually install them.
It would certainly help though. The statistics I've seen suggest that Apple has been pretty successful at getting users to upgrade and that's with a relatively manual upgrade process too:
I think that's due to numbers of devices sold rather than update behavior. I believe iOS had a large market share lead during the Android 1.x days, and that most of those 2.x devices were sold with 2.x. It's my understanding iOS users do a "better" job upgrading
After further thought, I'm wrong. I think the way this will actually play out is a little different.
When Loopt had this problem, we had to support all the broken devices, or the carrier wouldn't put us on deck at all. Now it's possible to just not offer (or even pull) the app on broken or non-standard devices. No bad reviews, less extra pain. Testing and feedback monitoring would still be required, but not fixing or hunting for work-arounds.
Then the burden would fall on device manufacturers (slowly -- consumer behavior would need to change). Consumers would stop buying phones that didn't have any apps.
I'm curious now to see what happens, and much less confident in my ability to predict the outcome. No matter how you look at it this is good news, and the result could be interesting and new.
What the parent is describing isn't so much OS version specific but device specific. If Samsung puts out a phone with a broken Android build on which the GPS is always faulty, as a developer, I can blacklist that device and my GPS reliant app won't show up on that device's Market.
Consumer buys that device, loads up the Market & tries looking for my app which their friend said was MUST HAVE. They don't find it on the Market so go back to the store, return the device & get another.
I think this is what kogir is talking about. Feel free to replace GPS with such things as broken OpenGL implementation, etc.
I think a more likely scenario is that the user can't find the app and gives up. I'm very much in favor of putting the power in developers' hands though.
The most refreshing thing about iOS development after years of web work is that I can make a number of simplifying assumptions about the target device. This eliminates a lot of wasted time and, more importantly, means I don't have to worry about the lowest common denominator and can really push the UI. If I have to go back to writing a lot of conditional hacks and progressive enhancement I think I'd rather just go back to web UI where my potential market is still 10x as big.
I agree that this makes development suck. I run a fairly popular Android app in my spare time, and I do everything I can to make it the best software possible. Now that I can generate an APK for specific device issues is just an overwhelming amount of/annoying work for a side project.
This is entirely off topic and pointless, but I enjoy seeing f7u12, as the numbers in it are directly attributable to me. You take what you can get, I guess!
> Multiple APK support gives you a variety of ways to control app distribution. For example, you could use it to create separate APKs for phones and tablets under the same product listing. You could also use it to take advantage of new APIs or new hardware capabilities without impacting your existing customer base.
The less fantastic news, is that your ratings will be averaged over each phone/tablet/API version. As you leave features out of older-API versions, those users will be unhappy and leave negative reviews.
Until Google presents reviews and ratings associated to specific versions, and now APKs, these reviews and ratings will continue to be problematic.
As you leave features out of older versions, those users will be unhappy and leave negative reviews.
Can you elaborate on what you mean by this? It seems like you're saying users will be unhappy because they can't get new features without having to update, which seems odd.
"UIRequiredDeviceCapabilities (Array or Dictionary - iOS) lets iTunes and the App Store know which device-related features an application requires in order to run. iTunes and the mobile App Store use this list to prevent customers from installing applications on a device that does not support the listed capabilities."
Agreed, but shouldn't you require users to have a camera to download a camera app? There's a key/value you should be able to add to your Info.plist to block devices without a camera...
One thing that I hope doesn't get lost amidst the jubilation is that I do not think that this changes the recommended way to create Android applications. Generally, developers should write applications to allow the same code run in as many different configurations as possible. Using the compatibility library should help developers create applications that are designed to scale from low-end phones to high-end tablets.
If anything, I believe that the biggest boon is not so much in creating device-specific builds, but being able to leave out some things that are unnecessary to keep application sizes low. If you know that a particular package is going to be used only on small, low-resolutions screens, there is no need to include the artwork for tablets.
I wish the market made a distinction between "reviews from people for whom the app is working" and "reviews from people for whom the app is broken". Most apps work fine on my G2, and it's useless when the first page of reviews is filled with 1-stars saying "FC's (force closes) on my Samsung Matrix Galactus++ Z".
If you have to test on all the devices and make individual builds for different devices, development sucks. I was at Loopt when we supported J2ME, where every phone that was supposed to be the same[1] was different, and per-device builds were the only solution. It was a nightmare. In the long term, I fear Android won't be much better in that regard.
[1] Java runs the same everywhere! All the JREs are validated by Sun and pass the same tests!