4 ms·

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

by briandh 13y ago

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.
- colin_mccabe 13y ago
  I developed for Android a few years ago (I don't do it any more), and I didn't find the documentation "horrific." There is JavaDoc for pretty much everything. Like anything else, there are a few dark corners, but mostly there are people discussing them online, so you can figure it out. I didn't use the SQLite API, but isn't the point of that API to "pollute" your code with SQL? I might be misunderstanding your complaint here-- do you believe the API shouldn't exist at all? Or that it's overused? It seems like there are a few cases where SQL is exactly what you need-- like building a finance program or something. With regard to the UI: I always saw the Layout classes as the View, the Activity as the Controller, and the Model as the classes that implemented the application itself. If anything, the big complaint people had seemed to be that Android was too structured, that it required you to do too much work before seeing anything on the screen. I agree that the XML files often seemed clunky, but at least you could vertically center a text box without magic, something that's apparently very difficult and unintuitive with HTML. Android also planned ahead for different screen sizes and form factors. The real "hack" (in the bad sense) is what Apple had to do when they made the iPad-- to run iPhone apps with doubled, blocky pixels to preserve the aspect ratio. Speaking of the "eternally inadequate GC", Android's GC has gotten better over time. MUCH better. I remember back in the 1.0 days 100 ms pauses were common. Now, the average is less than a tenth of that. The UI is still not as responsive as iOS, but it's getting there. I see no reason why the GC couldn't improve even more, with top people at Google working on it. With regard to the permissions thing: I agree with you here. It would really be nice to give users the ability to deny certain permissions to apps. As you mention, they probably don't do this because they don't want to destroy the business model of ad-supported apps that use the network. Hopefully some kind of solution can be reached here. I never actually developed for J2ME, but I knew a few folks who did, and they hated it. I remember tales of being stuck with Java circa 1.4 (no generics), ancient libraries, and even... ugh... Swing. I'm not that familiar with J2ME, so again, maybe it improved later on? Also, do you really think that delivering "100 different builds" (your words) is an easy thing for a company to do? With Android, I only need to deliver one build, and I have a store that can do most of the work for me. I think you are looking at the past through some seriously rose-tinted glasses.

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

by briandh 13y ago

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

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.

colin_mccabe 13y ago
I developed for Android a few years ago (I don't do it any more), and I didn't find the documentation "horrific." There is JavaDoc for pretty much everything. Like anything else, there are a few dark corners, but mostly there are people discussing them online, so you can figure it out. I didn't use the SQLite API, but isn't the point of that API to "pollute" your code with SQL? I might be misunderstanding your complaint here-- do you believe the API shouldn't exist at all? Or that it's overused? It seems like there are a few cases where SQL is exactly what you need-- like building a finance program or something. With regard to the UI: I always saw the Layout classes as the View, the Activity as the Controller, and the Model as the classes that implemented the application itself. If anything, the big complaint people had seemed to be that Android was too structured, that it required you to do too much work before seeing anything on the screen. I agree that the XML files often seemed clunky, but at least you could vertically center a text box without magic, something that's apparently very difficult and unintuitive with HTML. Android also planned ahead for different screen sizes and form factors. The real "hack" (in the bad sense) is what Apple had to do when they made the iPad-- to run iPhone apps with doubled, blocky pixels to preserve the aspect ratio. Speaking of the "eternally inadequate GC", Android's GC has gotten better over time. MUCH better. I remember back in the 1.0 days 100 ms pauses were common. Now, the average is less than a tenth of that. The UI is still not as responsive as iOS, but it's getting there. I see no reason why the GC couldn't improve even more, with top people at Google working on it. With regard to the permissions thing: I agree with you here. It would really be nice to give users the ability to deny certain permissions to apps. As you mention, they probably don't do this because they don't want to destroy the business model of ad-supported apps that use the network. Hopefully some kind of solution can be reached here. I never actually developed for J2ME, but I knew a few folks who did, and they hated it. I remember tales of being stuck with Java circa 1.4 (no generics), ancient libraries, and even... ugh... Swing. I'm not that familiar with J2ME, so again, maybe it improved later on? Also, do you really think that delivering "100 different builds" (your words) is an easy thing for a company to do? With Android, I only need to deliver one build, and I have a store that can do most of the work for me. I think you are looking at the past through some seriously rose-tinted glasses.