6 ms·

Unfortunately, the contents of this post are no surprise to any seasoned Android developer. It's very clear the Android engineers haven't given a lot of thought

Unfortunately, the contents of this post are no surprise to any seasoned Android developer. It's very clear the Android engineers haven't given a lot of thought to how applications are to be developed. I'm all for them not enforcing one methodology over another. However, in order to build an Android application (following whatever pattern) we do need core building blocks that have been well thought through on how they will be used. In general performing Async tasks (in particular networking) is excruciatingly convoluted on Android - well, at least to get it right. Many inexperienced Android developers simply get this wrong, and quite frankly I can't blame them. Such a common task should be trivial to perform and not require hours of background reading. The issue largely comes down to the fact the "system framework" has been designed to be simple (supposedly[1]) for system framework maintainers, and not developers writing applications. Destroying and recreating activities (so you can load different resources) may be simpler from AOSP's perspective, but it's not at all logical from the perspective of an application. Sure, there are several ways to work around this, but they're all stupidly convoluted. Frameworks should be written for consumers, not maintainers. [1] Okay, the system frameworks definitely aren't actually well designed / simple to work with for framework maintainers either, that was just the (missed) goal. If you want to see world's worst state machine (a stupid amount of booleans), check-out: http://stackoverflow.com/questions/17847775/nested-fragments-illegalstateexception-can-not-perform-this-action-after-onsa http://stackoverflow.com/questions/17847775/nested-fragments...

bigtones 10y ago
Yes, Dianne Hackborn was one of the main proponents and designers of the fragment system lamented in your StackOverflow question referenced: http://android-developers.blogspot.com/2011/02/android-30-fragments-api.html http://android-developers.blogspot.com/2011/02/android-30-fr...
lern_too_spel 10y ago
You've hit the nail on the head. It's not the system engineer's job to develop a useful application framework for common use cases any more than it is a Linux kernel developer's job to do so. Still, it has to be somebody's job, and it's clear that it isn't anybody's job on the Android team. For example, there's a hacky HTTP client library built by the Google Play Android client team (http://developer.android.com/training/volley/index.html http://developer.android.com/training/volley/index.html) that is promoted for general use for some silly reason, and to use it, you're supposed to copy the library's source code into your project. Pure amateur hour. There should be a team within Android building well-thought-out, properly versioned, and sanely distributed libraries to simplify Android application development. There should be, but there isn't.
- izacus 10y ago
  You mean like the sets of support libraries which make multi-versioned Android development significantly easier and less time consuming? I don't get the first-party library cargo cult that has developed on Android. What's wrong having the community develop libraries like on any other platform? There's a huge set of very good quality 3rd party Android libraries and even a great new language (Kotlin). As a dev I'd be rather that Google focuses on developing quality core blocks which cannot be fixed by community. Sadly it seems that Google developers simply do not know how to build good APIs, even new ones like MediaCodec, BLE APIs, updated storage APIs and permissions are an utter hard to use mess.
  - spbaar 10y ago
    There is no excuse for how hard the permissions API is to use. Why can we not know if the user has "never show again " checked directly? It literally looks like the API and ui came from different proposals
    - newjersey 10y ago
      Because you don't need to know. Permissions are sacred. If you don't have the permission, consider the capabilities aren't there and move on. How would you feel if Facebook or Instagram app refused to start if you didn't give it camera permission? Maybe I don't have a working camera in my Nexus 6.
      - curt15 10y ago
        The only real recourse against combat adversarial developers is to either trash the defective product in reviews or penalize the developers through other means. Holding functionality hostage in order to gain permissions should be instant grounds for rejection and/or further sanctions.
      - christop 10y ago
        Unfortunately, this is what Google's own app for the upcoming Google I/O conference does if you deny it access to your contacts at startup. If you grant the permission only to deny it later, the app won't start again until you grant the permission again. https://play.google.com/store/apps/details?id=com.google.samples.apps.iosched https://play.google.com/store/apps/details?id=com.google.sam...
piyush_soni 10y ago
I'd be curious to see how would Dianne respond to this, if you posted it on the Google+ page.
- Benjamin_Dobell 10y ago
  You're welcome to post a link here. It does seem like something the Android engineering team should hear (even if they have heard it before). Nonetheless, it's worth adding that my comment was written for the HN community. I'd usually be a bit more tactful (sic polite) when corresponding with someone directly. Also, my critique applies to the Android engineering team in general; singling Dianne out is probably a bit harsh.
ktRolster 10y ago
It's very clear the Android engineers haven't given a lot of thought to how applications are to be developed. The best quote from the article that backs up what you just said: "Heck, I only know about MVC from school." Hmmmm...
babuskov 10y ago
One could say the same thing for Win32 API. That's why you had Microsoft MFC, Borland VCL, wxWidgets, etc. running on top of it and making it more user friendly. The real problem seems to be that Android API is moving so fast, that it's risky to build such tools. The other problem is that these days most developers expect to get it for free, so there's no financial incentive to build it.
Aaargh20318 10y ago
Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Android as a platform today. First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 activity per screen no longer makes any sense anymore either. Second, the decision to go with Java as a language. After they make us jump through ridiculous hoops to fit our applications into their stupid activity model just to save RAM, they go waste it by chosing a GC'd language, combined with the performance hit you take for the VM this this has really hurt Android app performance. In return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM. But, I hear you say, you can supply JNI binaries for multiple architectures. Sure you can, if you can fit them in your APK, which you can't because your APK is limited to 50MB because it has to be downloaded to a temp partition before installing. This brings us to the thirds major fuckup: the file system on Android, or specifically the fact that there are several filesystems instead of just the one. But hey, at least now we get to support removable storage, which is both a PITA for developers, extremely confusing for end-users (why can't I install this app when I have gigabytes of free space on my SD card ?) and after all that trouble hardly any phone has removable storage anymore. This seems to be the big problem with Android's development: a complete lack of vision by Google. They never designed for tomorrows hardware, instead they designed for last years hardware. Android is an OS built around hardware limitations that no longer existed by the time it gained momentum. It's like they were completely surprised by the speed at which mobile hardware evolved.
- izacus 10y ago
  > n return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM. These sentences are utter lies that have no basis in reality. Most applications do not use native code and even those that can mostly do have x86 binaries available. There's also significantly more than 0.1% of non-ARM devices, not to mention the fact that Android currently runs targeting three different ARM architectures. Also having worked on a rather huge NDK project that barely hits 15MB of native code I seriously have to wonder how is 100MB limit (not 50MB as you say, since that was lifted) a problem code-wise. Resource-wise yes (and OBB system is kinda crap), but 50MB of compressed binary?!
mirsadm 10y ago
Poorly designed APIs are a common theme with Android. Another example is the MediaCodec APIs for hardware video encoding. They are so awful compared to iOS that it makes me think twice about buying another Nexus phone. It is impossible to design a nice real time video application while targeting a significant number of Android devices.
TeMPOraL 10y ago
> Frameworks should be written for consumers, not maintainers. Welcome to Worse is Better. This is literally what Unix went against. People used to write that way before; now it has to be easiest for platform developer/maintainer.
vvanders 10y ago
My favorite one is Button, it inherits from... TextView. Doesn't contain a TextView, inherits. Ugh.
- HillaryBriss 10y ago
  Yeah. And "ImageButton" is a subtype of "ImageView" so it isn't a "Button". But it has button states.

bigtones 10y ago

Yes, Dianne Hackborn was one of the main proponents and designers of the fragment system lamented in your StackOverflow question referenced: http://android-developers.blogspot.com/2011/02/android-30-fragments-api.html http://android-developers.blogspot.com/2011/02/android-30-fr...

lern_too_spel 10y ago

You've hit the nail on the head. It's not the system engineer's job to develop a useful application framework for common use cases any more than it is a Linux kernel developer's job to do so. Still, it has to be somebody's job, and it's clear that it isn't anybody's job on the Android team. For example, there's a hacky HTTP client library built by the Google Play Android client team (http://developer.android.com/training/volley/index.html http://developer.android.com/training/volley/index.html) that is promoted for general use for some silly reason, and to use it, you're supposed to copy the library's source code into your project. Pure amateur hour. There should be a team within Android building well-thought-out, properly versioned, and sanely distributed libraries to simplify Android application development. There should be, but there isn't.

izacus 10y ago
You mean like the sets of support libraries which make multi-versioned Android development significantly easier and less time consuming? I don't get the first-party library cargo cult that has developed on Android. What's wrong having the community develop libraries like on any other platform? There's a huge set of very good quality 3rd party Android libraries and even a great new language (Kotlin). As a dev I'd be rather that Google focuses on developing quality core blocks which cannot be fixed by community. Sadly it seems that Google developers simply do not know how to build good APIs, even new ones like MediaCodec, BLE APIs, updated storage APIs and permissions are an utter hard to use mess.
- spbaar 10y ago
  There is no excuse for how hard the permissions API is to use. Why can we not know if the user has "never show again " checked directly? It literally looks like the API and ui came from different proposals
  - newjersey 10y ago
    Because you don't need to know. Permissions are sacred. If you don't have the permission, consider the capabilities aren't there and move on. How would you feel if Facebook or Instagram app refused to start if you didn't give it camera permission? Maybe I don't have a working camera in my Nexus 6.
    - curt15 10y ago
      The only real recourse against combat adversarial developers is to either trash the defective product in reviews or penalize the developers through other means. Holding functionality hostage in order to gain permissions should be instant grounds for rejection and/or further sanctions.
    - christop 10y ago
      Unfortunately, this is what Google's own app for the upcoming Google I/O conference does if you deny it access to your contacts at startup. If you grant the permission only to deny it later, the app won't start again until you grant the permission again. https://play.google.com/store/apps/details?id=com.google.samples.apps.iosched https://play.google.com/store/apps/details?id=com.google.sam...

piyush_soni 10y ago

I'd be curious to see how would Dianne respond to this, if you posted it on the Google+ page.

Benjamin_Dobell 10y ago
You're welcome to post a link here. It does seem like something the Android engineering team should hear (even if they have heard it before). Nonetheless, it's worth adding that my comment was written for the HN community. I'd usually be a bit more tactful (sic polite) when corresponding with someone directly. Also, my critique applies to the Android engineering team in general; singling Dianne out is probably a bit harsh.

ktRolster 10y ago

It's very clear the Android engineers haven't given a lot of thought to how applications are to be developed. The best quote from the article that backs up what you just said: "Heck, I only know about MVC from school." Hmmmm...

babuskov 10y ago

One could say the same thing for Win32 API. That's why you had Microsoft MFC, Borland VCL, wxWidgets, etc. running on top of it and making it more user friendly. The real problem seems to be that Android API is moving so fast, that it's risky to build such tools. The other problem is that these days most developers expect to get it for free, so there's no financial incentive to build it.

Aaargh20318 10y ago

Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Android as a platform today. First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 activity per screen no longer makes any sense anymore either. Second, the decision to go with Java as a language. After they make us jump through ridiculous hoops to fit our applications into their stupid activity model just to save RAM, they go waste it by chosing a GC'd language, combined with the performance hit you take for the VM this this has really hurt Android app performance. In return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM. But, I hear you say, you can supply JNI binaries for multiple architectures. Sure you can, if you can fit them in your APK, which you can't because your APK is limited to 50MB because it has to be downloaded to a temp partition before installing. This brings us to the thirds major fuckup: the file system on Android, or specifically the fact that there are several filesystems instead of just the one. But hey, at least now we get to support removable storage, which is both a PITA for developers, extremely confusing for end-users (why can't I install this app when I have gigabytes of free space on my SD card ?) and after all that trouble hardly any phone has removable storage anymore. This seems to be the big problem with Android's development: a complete lack of vision by Google. They never designed for tomorrows hardware, instead they designed for last years hardware. Android is an OS built around hardware limitations that no longer existed by the time it gained momentum. It's like they were completely surprised by the speed at which mobile hardware evolved.

izacus 10y ago
> n return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM. These sentences are utter lies that have no basis in reality. Most applications do not use native code and even those that can mostly do have x86 binaries available. There's also significantly more than 0.1% of non-ARM devices, not to mention the fact that Android currently runs targeting three different ARM architectures. Also having worked on a rather huge NDK project that barely hits 15MB of native code I seriously have to wonder how is 100MB limit (not 50MB as you say, since that was lifted) a problem code-wise. Resource-wise yes (and OBB system is kinda crap), but 50MB of compressed binary?!

mirsadm 10y ago

Poorly designed APIs are a common theme with Android. Another example is the MediaCodec APIs for hardware video encoding. They are so awful compared to iOS that it makes me think twice about buying another Nexus phone. It is impossible to design a nice real time video application while targeting a significant number of Android devices.

TeMPOraL 10y ago

> Frameworks should be written for consumers, not maintainers. Welcome to Worse is Better. This is literally what Unix went against. People used to write that way before; now it has to be easiest for platform developer/maintainer.

vvanders 10y ago

My favorite one is Button, it inherits from... TextView. Doesn't contain a TextView, inherits. Ugh.

HillaryBriss 10y ago
Yeah. And "ImageButton" is a subtype of "ImageView" so it isn't a "Button". But it has button states.