It seems to me that the best way to think of Android is to compare it to the world of Linux distros. (I believe Dan Benjamin of 5by5 pointed this out on one of his podcasts.) Yes, there's Linux, but there's no one Linux. There's Android, but there's no one Android.
So while Android is technically an operating system, it's really an open platform on which to build mobile devices on top of. So the Android device I buy is that vendor's take on the hardware and the software. Google has its own take, as does Amazon, as does Samsung.
When viewed in that frame, it's not so frustrating or confusing, or even an actual problem. Fragmentation can be viewed as a natural consequence of the open Android ecosystem.
Spoken like someone who isn't an Android developer.
Take your analogy to the next step. Someone opens an online store that sells binary-only copies of applications targeted to just "Linux".. you would call them crazy, no? That's what the Google Market is. Or the Amazon Market, samsung apps, nook store, ...
I wrote a blog post to help you understand the pragmatic issues faced by an Android developer trying to write decent software.
Your blog post blames a bug on Android fragmentation, but it sounds like it was your fault. You were not calling Environment.getExternalStorageDirectory(), which is the portable way of accessing the storage area where users saves file via USB mount.
I tend to find that with Android success is directly proportional to how much the platform is embraced as it is. Many people seem to approach it as a slightly different Linux, iOS or J2ME/J2SE and get very disappointed. If you fight it it will bite you in exactly that sort of way.
The problem is the API is huge, and the documentation isn't great either, so you're supposed to learn best practice from the apps in the OS source tree.
That API call is not sufficient. Some devices have more than one external storage device. For example some tablets have an internal storage point and the ability to have a USB key.
The function you are talking about only returns a single directory and my users want to use both if available.
It really isn't a big deal. Use reflection to find what works at runtime, and live with it. That's the price of the flexibility which makes the whole thing attractive in the first place.
The big problem is trying to cover all bases from the start: you won't. Attack it like an old school PC shareware dev, and respond to customer requests.
There are far larger problems with Android than this kind of thing. That things on external storage basically bypass the security model is a much bigger concern.
The brutal part is that generally customer requests are no better than "the bug is shitty app" or just "buggggggg". Thats where a responsive strategy sucks - reliable reports are few and far between.
On fragmentation, your blog post is exactly backwards.
You're calling out hardware fragmentation, but that's exactly the fragmentation the consumer wants - they see it in the store and pick it (via form factor, price, etc.). Beyond that, Android couldn't rein in hardware fragmentation without being something utterly unrecognizable. On Android dealing with hardware fragmentation is your job, just as it is in the desktop/laptop/netbook/... world.
Software fragmentation is the fragmentation consumers can't see and, generally speaking, don't want. And that's the fragmentation that is often preventable, as CyanogenMod's porting success demonstrates.
I think there's plenty of evidence that users want the hardware choices they make:
1. Apple's strongest competitor, Samsung is probably the world record holder for number of different smartphone models / form factors sold simultaneously. Even with the Galaxy S II family as their top sellers, they aren't the bulk of its portfolio. While there are some experiments in there (like the Note was), I'm sure they're not setting that record just for the fun of it. If some people didn't want those choices, Samsung's smartphone strategy would not be viable.
2. The Galaxy S II isn't almost identical to the iPhone hardware. You can (and Apple and Samsung do) argue about the level of aesthetic similarity, but there are many hardware differences: size, screen, removable battery, microSD slot ... and all of these differences are things a customer can easily see in a store.
3. One of the dimensions that users obviously want choice is price - and that leads to hardware fragmentation all by itself (by using cheaper or more expensive components depending on the target price).
4. More than a few experienced iPhone users have specifically talked about switching from an iPhone to the Galaxy Note. They all talk about making the switch because of hardware differences.
Right, the problem is with the Google Market, Amazon Market, et. al. It's not with Android as a platform (or operating system).
The problem is that Google copied the "App Store" idea for software distribution that Apple created for their iPhone. Instead, they should have gone with the same idea that Linux distros use: The product vendor is responsible for distributing the software for the product. That would look completely different from what we have now, but it would be a more natural fit to what Android really is.
Also, you could have made your point just as well without the ad hominem.
I don't see a personal attack in my message. Your original post suggested that android fragmentation is not a problem if I just think of it differently. A logical extension of that is that it's my fault for seeing it as a problem as I'm dealing with it incorrectly.
That doesn't make my users any happier. It doesn't make their bug reports go away. That doesn't make their phones all mount to the same mountpoint. It doesn't make me sleep better at night.
That's not an attack. Neither is claiming your viewpoint is one of a non-developer because pragmatically speaking a developer deals with these problems daily so "thinking of it differently" really makes no difference to the size of the problem.
Please don't accuse me of a logical fallacy here, thank you.
That's a horrible idea. Instead of hardware fragmentation we'd be stuck with market fragmentation. I have zero confidence in the manufacturers' abilities to foster a good marketplace. And they would have a monetary incentive to disable access to other marketplaces and sideloading, so there wouldn't be any competition, either.
So because it's a "natural consequence" it's not an actual problem? Sorry.
Distribution on Linux can be a similar nightmare. Try downloading a source package to find that it requires version 2.3 of LibExample, and you have version 2.2, but the developers didn't know they needed 2.3 and the configure script doesn't detect the discrepancy, so you get some cryptic compilation error halfway through. Binary distribution on Linux is possible, the Xonotic folks did it, but it's a lot of work. Android development is more forgiving since the API as a whole is versioned, but portable programming is still more work.
Diversity of hardware and software isn't an inherent boon, it's just something that brings its own benefits and drawbacks.
>Diversity of hardware and software isn't an inherent boon, it's just something that brings its own benefits and drawbacks.
Absolutely. Also, fragmentation is more of an issue in Asia where there are literally hundreds of cheaper variations of the same phone with different Android versions, screen sizes, memory, etc.
The alternative isn't for all these devices of different sizes and capabilities not to exist. The alternative is for them all the be running even more disparate, vendor-specific operating systems. We should be thankful for the degree of unification Android's success has brought.
One of the annoyances I've had with Android, from a new consumer's point of view, is that it's presented as this monolithic OS that's the same across every phone. But once you do the research, you find that it's really not. Except for the Nexus line, there really isn't a "Google Android" experience. When you buy an Android device, you're really buying HTC's, Samsung's, Amazon's or Motorola's Android. Every device has different capabilities. Some ship with different Google services out of the box, others ship with their own internal apps. Google's Android strategy is that every manufacturer can make their own Android shell, without placing any requirements on the vendors as to what version of Android they're using.
It's a great thing that there's all this choice for the devices. It's a great thing that Android allows this kind of freedom. But it's led to a lot of issues for Google and for developers.
The problem that Google has is that they've effectively lost control of Android. They can't force manufacturers to use the latest version of Android. So they're left with situations like this, where the vast majority of Android devices are running an old version of the OS, and will never be updated to the newest version, because the manufacturers just don't want to[1]. So the result is that they have to support around 4 different codelines at the same time(ICS, HC, Gingerbread, and Froyo).
It's a problem for developers because your display code might not look right on a new device with a weird screen resolution. Or you might need API calls that are only in 4.0, which would lock you out of 90% of the devices right now.
No, the alternative is for Google to exert control over the device manufacturers and state that if they're going to be using the Android OS, they need to support and update their devices to the latest version for at least 2 years after the phones are released.
[1] There is a good economic argument that patching phones that are 18 months old with 24 month contracts about to be up just doesn't make sense, but honestly, it comes down to that the manufacturers just aren't willing to do it.
"No, the alternative is for Google to exert control over the device manufacturers and state that if they're going to be using the Android OS, they need to support and update their devices to the latest version for at least 2 years after the phones are released."
You think that would cause the manufacturers to change their behavior in order to stay certified as Android compatible? I think that would lead the major manufacturers to fork Android, like Amazon has done for the Kindle Fire.
Unfortunately, I don't that any of the manufacturers would listen to that.
Ultimately, I think it's on Google's head to do this. I've said in previous posts that Google should have handled the Android trademark a lot like how Mozilla handles their trademarks. Android, the OS, is free to use(both as in Speech and Beer), but if you're going to make major changes(i.e. the standard services and applications, limit install privileges, etc.), then the manufacturer cannot use the Android trademarks in their advertising, and can only use a "Powered by Android" mark.
Manufacturers that comply with Google's requirement could brand their phone as a full Android phone.
'We define an "Android compatible" device as one that can run any application written by third-party developers using the Android SDK and NDK. We use this as a filter to separate devices that can participate in the Android app ecosystem, and those that cannot. Devices that are properly compatible can seek approval to use the Android trademark. Devices that are not compatible are merely derived from the Android source code and may not use the Android trademark.'
But there is a huge difference. First, that desktop OS are ready for differences in hardware. As a developer, you usually don't care about screen size, or processor, or memory.
With Android, you have to. Some devices will not be capable to run your app, in some others your app will not even fit the screen... And, of course, because of different drivers, hardware and OS versions your app will not absolutely work on some phones because of some weird error. It's nowhere near Linux development.
I don't know if fragmentation is good or bad for the users, but for developers it's an infinite source of headaches. From my experience (I develop a Twitter client for WP7), even with a system with much less fragmentation than Android, every phone has unique features which can make your app crash for no reason, and you can only wait to be randomly corrected or get that specific model and debugging the app.
I don't think so. Even desktop OSes are not ready for such vast differences of today's hardwares.
Desktop-PC usually have approximately 100dpi screens, so the OS and the app generally don't consider dpi differences. So, if you've ever got a high dpi screen for Windows, you'll see the icons are frigging small.
Whereas, on mobile platform, we have screens ranging from 80dpi to above 300dpi. Android take dpi differences into account in the first place, to make sure, a same icon have almost same size on different dpi screens. It's a start.
I much doubted Microsoft or Apple would deal better with 'retina' desktop-pc coming in. Real trouble have just begun...
"When viewed in that frame, it's not so frustrating or confusing, or even an actual problem"
Androids main competition allows developers to reach a similar sized user base which targeting a tiny fraction of devices. When it comes time to decide which platform to support or which to support first the answer becomes moot.
If that is "not ... even an actual problem" under the frame of reference you're talking about... all that tells us is that that frame of reference is probably bad. Which sounds about right given that neither is desktop linux a great consumer success story nor are linux distro's held hostage by a third party.
Imagine if you had to wait for Time Warner's permission to update linux, oh I think that would be bad...
One difference between different linux distros and android is that, in the former case, end users recognize that software written for another distro may not work on their specific OS. In the latter case, however, end users (especially ones that aren't technical) think that they have the same OS (when in reality they all own phones with different levels of API support / compatibility) and are upset when a specific app does not work as expected on their device.
It actually reminds me of the Personal Computer when I was growing up. There was Apple (a bit of a mushroom very few people had) and IBM (your dad's business computer), plus a whole bunch of IBM clones (even Samsung made one). All of the clones ran the same OS (or version thereof).
Obviously there are some huge differences, but it still feels very familiar to me. I don't think it'll play out the same though, given the quality and popularity of the Apple product this time around.
As much as I do appreciate Apple products, I'm glad they lost the PC revolution. I can't believe we'd have been better off building software for that closed system.
It's close to that, but not quite. Android is a bit more centralized, so apps are pretty much guaranteed to work on all versions of Android, while on Linux you need different packages for different distros and so on.
But I do think Google could do a lot more to centralize and standardize the platform and the app ecosystem.
The difference is Linux has its act together. Android doesn't.
Right now I can SSH into a vastly different array of hardware and update a roughly equivalent set of packages to get for example the latest rendering engine or security fixes. This is not possible at all on Android which is a joke. And I will never understand how people such as yourself can defend it.
Fragmentation is a huge issue for Android and it is only going to get worse unless Google does something about it.
Google has created an open ecosystem, and these are the natural consequences. Google can't "do something about it" because of the open terms of their licensing.
The messy truth is that Google has created only a half-open ecosystem. 98%+ of Android users are at the mercy of the carriers and handset makers for updates. That's not a truly open ecosystem.
Even if 100% of users were at the mercy of carriers and handset makers, that just underscores that 'Google can't "do something about it"'; it doesn't even mean the platform is not "open", as you are mistaking open devices for open software: the platform is, in fact, so open that carriers and handset manufacturers are allowed to make arbitrary modifications and sell closed devices running the result.
I think a better analogy is a web browser. There are many versions, many resolutions, but they all roughly support the same API, while modern browsers have more features.
So while Android is technically an operating system, it's really an open platform on which to build mobile devices on top of. So the Android device I buy is that vendor's take on the hardware and the software. Google has its own take, as does Amazon, as does Samsung.
When viewed in that frame, it's not so frustrating or confusing, or even an actual problem. Fragmentation can be viewed as a natural consequence of the open Android ecosystem.