3 ms·

So, this is a related rant that's been brewing . . . Historical revisionism is a wonderful thing, apparently. Reviewing where Android was when it launched, a g

So, this is a related rant that's been brewing . . . Historical revisionism is a wonderful thing, apparently. Reviewing where Android was when it launched, a good few years after these events, and you can only conclude Samsung were 100% right. Android had a slow VM (far slower than the others already in the market) very high system requirements, and represented a whole new incompatible ecosystem. Much of the world had moved on to J2ME's MIDP 2.0, with Japan and the US the notable exceptions with i-mode and Qualcomm's C based Brew platform respectively. As later happened with Android the fragmentation problems of J2ME were greatly exaggerated by a whole mini industry of companies reliant on the illusion. J2ME certainly had problems, but if you were delivering more than 100 different builds (I'm aware of groups pushing 1000) then you were completely and absolutely insane. It might sound like creating 100 different builds would be a big problem, but the differences were really fairly trivial, and not much worse than Android today which primarily benefits from most of the OS having been written by one group, except for the driver layers, whereas previously a lot more was on the OEM. I'm a fairly loud proponent of the merits of Android, but what is even more widely ignored is that J2ME was in many ways superior to it, most obviously in the way it handled application permissions. For those that have dug into the platform it's amazingly clear that without the iPhone coming along and spurring Google on to greater things Android would have been a complete non-event at launch, especially with the dire performance of the early devices. The concern for Android developers today is that now Google have done just enough to edge out the iPhone in the market (though not in terms of developer experience, thanks to the giant incoherent mess of an API) they're leaving the platform to stagnate. Perversely the best thing for Android devs right now would be if Apple or MS produce an absolutely killer version of their respective OS's forcing Google to invest where it's needed to stay in contention. So I certainly wouldn't rate Samsung as a software outfit, they're notably terrible, but Google have caught many of the old MS diseases, especially when it comes to doing only enough to destroy competitors and then leaving it hanging. If you compare the iOS and Android APIs you can't escape the conclusion that the iOS team have pride in their work, and the Android team are constantly having to make excuses for what a rush they were in. Both groups drove the other to greater heights, but the impact both eventually had in the market is only thanks to the other having driven them to get there.

RyanMcGreal 13y ago
"No wireless. Less space than a nomad. Lame."
briandh 13y ago
Out of genuine curiosity, in what respects do you think Google is allowing Android to "stagnate"?
- fidotron 13y ago
  A few large areas: Data storage The SQLite API is a mess (you end up with SQL polluting a frightening amount of code once you start using it), along with associated content providers and the way this stuff attaches to views. This is particularly noticeable around the MediaStore, which is one of the truly horrendously fragmented areas of the system. If I had more faith in the future of the platform this is what I'd attack first as the potential for improvement for developers and end users is immense. UI framework The very core of the layout algorithm (where it traverses the views for information) is about as wrong as it can be while still appearing to function. Using styling or animations results in a horrifying explosion of xml files edited by the slowest xml editor in existence. They need a decent MVC UI system (the Cocoa killer feature), not this hacked together mess. Whoever came up with Fragments does deserve a medal though. General API cleanup The API has inconsistent naming and code style throughout. A lot of it is clearly the work of people more comfortable in C or C++ writing Java for the first time, but there are packages where NIH syndrome seems to have occurred between different groups of the Android core team. One of the NS* API features is even thoughTheNamesAreSoLongJavaCantCompete at least they understand the benefit of consistency, whereas in Android every package feels unique. J2ME was superior to Android in this respect, and the people designing it also knew when to use primitives and when to use objects. Android uses too many objects for things like touch events, resulting in far too big a load on the eternally inadequate garbage collector. Permissions They need to actually launch the feature whereby you can install an app but deny it permission for particular operations. I suspect once they proxy ad stuff through Play Services they'll try to switch this on, as if they did it right now 90% of the noise would be ad supported app devs complaining users are disabling their network connections. Finally, relatedly, the documentation is horrific. It's quite common to find references in examples to methods that don't exist (and the examples written in yet another bizarre coding style), or magic details are referred to but not demonstrated or explained. I have got more useful info by reading the source for the system itself. If you go and read the source for a project like DashClock any reasonable developer goes and cries in a corner. That's PHP4 style development, not the way you preserve sanity over a long period of time. At least the storage and UI could be added in a compatibility library, so the fragmentation argument wouldn't apply. Kitkat has added superficial improvements for some areas, but again it's just enough to allow users to not notice the gaps with iOS, while leaving many Android devs spending a disproportionate amount of time adding stupid hacks to paper over the inadequacies of the platform.

RyanMcGreal 13y ago

"No wireless. Less space than a nomad. Lame."

briandh 13y ago

Out of genuine curiosity, in what respects do you think Google is allowing Android to "stagnate"?

fidotron 13y ago
A few large areas: Data storage The SQLite API is a mess (you end up with SQL polluting a frightening amount of code once you start using it), along with associated content providers and the way this stuff attaches to views. This is particularly noticeable around the MediaStore, which is one of the truly horrendously fragmented areas of the system. If I had more faith in the future of the platform this is what I'd attack first as the potential for improvement for developers and end users is immense. UI framework The very core of the layout algorithm (where it traverses the views for information) is about as wrong as it can be while still appearing to function. Using styling or animations results in a horrifying explosion of xml files edited by the slowest xml editor in existence. They need a decent MVC UI system (the Cocoa killer feature), not this hacked together mess. Whoever came up with Fragments does deserve a medal though. General API cleanup The API has inconsistent naming and code style throughout. A lot of it is clearly the work of people more comfortable in C or C++ writing Java for the first time, but there are packages where NIH syndrome seems to have occurred between different groups of the Android core team. One of the NS* API features is even thoughTheNamesAreSoLongJavaCantCompete at least they understand the benefit of consistency, whereas in Android every package feels unique. J2ME was superior to Android in this respect, and the people designing it also knew when to use primitives and when to use objects. Android uses too many objects for things like touch events, resulting in far too big a load on the eternally inadequate garbage collector. Permissions They need to actually launch the feature whereby you can install an app but deny it permission for particular operations. I suspect once they proxy ad stuff through Play Services they'll try to switch this on, as if they did it right now 90% of the noise would be ad supported app devs complaining users are disabling their network connections. Finally, relatedly, the documentation is horrific. It's quite common to find references in examples to methods that don't exist (and the examples written in yet another bizarre coding style), or magic details are referred to but not demonstrated or explained. I have got more useful info by reading the source for the system itself. If you go and read the source for a project like DashClock any reasonable developer goes and cries in a corner. That's PHP4 style development, not the way you preserve sanity over a long period of time. At least the storage and UI could be added in a compatibility library, so the fragmentation argument wouldn't apply. Kitkat has added superficial improvements for some areas, but again it's just enough to allow users to not notice the gaps with iOS, while leaving many Android devs spending a disproportionate amount of time adding stupid hacks to paper over the inadequacies of the platform.