6 ms·

Well if Linus had worked with any android apis, he wouldn't be the least surprised by completely illogical APIs coming out of Google (or making once completely

Well if Linus had worked with any android apis, he wouldn't be the least surprised by completely illogical APIs coming out of Google (or making once completely logical APIs illogical).

Varriount 3y ago
Are the Android APIs that bad? (I've yet to develop an Android app)
- londons_explore 3y ago
  The user-visible API's aren't great, but okayish. The innards are spaghetti.
  - ihuk 3y ago
    I would argue that a lot of public APIs are a mess. We used to joke that instead of firing the bottom 10%, Google just reallocates them to the Android team.
    - pjmlp 3y ago
      During the early days Android APIs were clearly written by C folks with zero experience in Java programming culture.
      - izacus 3y ago
        During the early days the APIs were written by folks who had to make Java OS work on a 550MHz ARM, 192MB of RAM with software rendering. "Java programming culture" outright would not work which was obvious to anyone trying to write fast code back then. (I also wonder how many users are willing to trade off 15% of their battery time to developer java programming culture.)
        josefx 3y ago
        Java was running on feature phones well before android was a thing. > "Java programming culture" outright would not work which was obvious to anyone trying to write fast code back then. And yet Google had enough air to use a half working third party implementation instead of using the bleeding edge Sun JRE. > (I also wonder how many users are willing to trade off 15% of their battery time to developer java programming culture.) Apparently many people don't run an adblocker on their mobile browser, so the number of people who don't care must be rather high.
        izacus 3y ago
        Not that Java. Please don't bring JavaME into "API quality" debate because it's only place is to be ridiculed on the garbage dump of history. Android was running a full JavaSE on a much larger and higher resolution screen. There's a reason why it lived and all other Java OSes miserably died.
        pjmlp 3y ago
        The reason being Google ripped off Sun, and gave Android as free beer to OEMs willing to close their eyes to the way Sun was screwed. In the end they didn't even bother to make an offer for Sun's assets. Why bother, they already got what they wanted. Unfortunately Oracle failed to put them into their place, as Sun did previously with Microsoft.
        pjmlp 3y ago
        Except you're talking to a former Nokia employee that knows enough about Symbian and J2ME, and had enough of Dalvik falsehoods regarding JVM implementation techniques on constrained devices.
        izacus 3y ago
        Yes, I remember meeting many Nokia employees at that time (when there was a still a Nokia Symbian vs. iPhoneOS vs. Android race in progress) and they all seemed to be on the wrong planet when it came to developer mindset. I distinclty remember Nokia trying to sell us on Qt app development... where apps were only actually able to run on like 2 devices out of their 100+ device portfolio. It was hillarious how misguided they were.
- izacus 3y ago
  Only for people who haven't developed for any other OS :P There are some APIs that are real stinkers (and quite a few of them obviously targeted at use of a single Google app and noone cared to actually make them good APIs). Several of them are really well thought out and designed to the point that iOS devs were envious for years. Gain some, lose some. It's not the best API surface, but it aint GTK or Win32 either.
  - whoisthemachine 3y ago
    I haven't worked with GTK, but I can agree that Win32's APIs are also a mess, affected by decades of layers of compatibility. The WinForms API, however, still tends to be quite nice.
- Izkata 3y ago
  The notification API has changed so much that it requires a Google compatibility library to target more than one Android version.
  - izacus 3y ago
    Yeah, that's not a bad thing (Notification implementation in general is one of the parts of Android that's consistently better than iOS in most user research).
  - whoisthemachine 3y ago
    Agreed, one of the API's that has undergone superfluous changes that are hard to reason about. My favorite one is `service.stopForeground(...)`. It used to take a true/false which meant either remove the notification or not. Such control coupling is a questionable design decision in the first place, but then the API was morphed to now to take a tri-state flag that, from what I can tell, means essentially the same thing as the old boolean flag, but let them avoid fixing a bug in old behavior. For over a decade, it seems that no one has stopped to ask why notifications and service foreground state are coupled so in the API in the first place. [0] https://developer.android.com/reference/android/app/Service#stopForeground(int) https://developer.android.com/reference/android/app/Service#... [1] Control Coupling - https://en.wikipedia.org/wiki/Coupling_%28computer_programming%29#Procedural_programming https://en.wikipedia.org/wiki/Coupling_%28computer_programmi...
londons_explore 3y ago
The android codebase is so huge there is nobody who really has a good view at all of it to make architectural decisions. Also internal politics sometimes impacts technical decisions ("No, you can't add an API to our teams codebase - we're underresourced and don't have time to review your changes till Q4 2025"). End result: API's are added in silly places.
- ykonstant 3y ago
  On second thought, let's not go to Camelot.
cmrdporcupine 3y ago
My experience is that Google code reviews tend on the whole to get so caught up in stylistic and micro-level technical comments that overall design gets lost in the shuffle. Especially in something really large and old and evolved like Android or Chromium. In general the code review process can work at Google for most projects because the essential design questions are already set in stone. You use protobuf/gRPC, follow the patterns that other services have mandated. There is usually a "recipe." And within Google design problems are perhaps sometimes addressed during PRD/design-doc phase, in a big Google Doc. But not always. But I can see how this could completely fall over when these things go out into the external world. That and the need to make everything into small microlevel reviews that get nitpicked for days means that large wholesale architecture simplifications and refactors just don't really happen very often. Few projects have people with that kind of authority. The Torvalds review is pretty savage.

Well if Linus had worked with any android apis, he wouldn't be the least surprised by completely illogical APIs coming out of Google (or making once completely logical APIs illogical).

Varriount 3y ago

Are the Android APIs that bad? (I've yet to develop an Android app)

londons_explore 3y ago
The user-visible API's aren't great, but okayish. The innards are spaghetti.
- ihuk 3y ago
  I would argue that a lot of public APIs are a mess. We used to joke that instead of firing the bottom 10%, Google just reallocates them to the Android team.
  - pjmlp 3y ago
    During the early days Android APIs were clearly written by C folks with zero experience in Java programming culture.
    - izacus 3y ago
      During the early days the APIs were written by folks who had to make Java OS work on a 550MHz ARM, 192MB of RAM with software rendering. "Java programming culture" outright would not work which was obvious to anyone trying to write fast code back then. (I also wonder how many users are willing to trade off 15% of their battery time to developer java programming culture.)
      - josefx 3y ago
        Java was running on feature phones well before android was a thing. > "Java programming culture" outright would not work which was obvious to anyone trying to write fast code back then. And yet Google had enough air to use a half working third party implementation instead of using the bleeding edge Sun JRE. > (I also wonder how many users are willing to trade off 15% of their battery time to developer java programming culture.) Apparently many people don't run an adblocker on their mobile browser, so the number of people who don't care must be rather high.
        izacus 3y ago
        Not that Java. Please don't bring JavaME into "API quality" debate because it's only place is to be ridiculed on the garbage dump of history. Android was running a full JavaSE on a much larger and higher resolution screen. There's a reason why it lived and all other Java OSes miserably died.
        pjmlp 3y ago
        The reason being Google ripped off Sun, and gave Android as free beer to OEMs willing to close their eyes to the way Sun was screwed. In the end they didn't even bother to make an offer for Sun's assets. Why bother, they already got what they wanted. Unfortunately Oracle failed to put them into their place, as Sun did previously with Microsoft.
      - pjmlp 3y ago
        Except you're talking to a former Nokia employee that knows enough about Symbian and J2ME, and had enough of Dalvik falsehoods regarding JVM implementation techniques on constrained devices.
        izacus 3y ago
        Yes, I remember meeting many Nokia employees at that time (when there was a still a Nokia Symbian vs. iPhoneOS vs. Android race in progress) and they all seemed to be on the wrong planet when it came to developer mindset. I distinclty remember Nokia trying to sell us on Qt app development... where apps were only actually able to run on like 2 devices out of their 100+ device portfolio. It was hillarious how misguided they were.
izacus 3y ago
Only for people who haven't developed for any other OS :P There are some APIs that are real stinkers (and quite a few of them obviously targeted at use of a single Google app and noone cared to actually make them good APIs). Several of them are really well thought out and designed to the point that iOS devs were envious for years. Gain some, lose some. It's not the best API surface, but it aint GTK or Win32 either.
- whoisthemachine 3y ago
  I haven't worked with GTK, but I can agree that Win32's APIs are also a mess, affected by decades of layers of compatibility. The WinForms API, however, still tends to be quite nice.
Izkata 3y ago
The notification API has changed so much that it requires a Google compatibility library to target more than one Android version.
- izacus 3y ago
  Yeah, that's not a bad thing (Notification implementation in general is one of the parts of Android that's consistently better than iOS in most user research).
- whoisthemachine 3y ago
  Agreed, one of the API's that has undergone superfluous changes that are hard to reason about. My favorite one is `service.stopForeground(...)`. It used to take a true/false which meant either remove the notification or not. Such control coupling is a questionable design decision in the first place, but then the API was morphed to now to take a tri-state flag that, from what I can tell, means essentially the same thing as the old boolean flag, but let them avoid fixing a bug in old behavior. For over a decade, it seems that no one has stopped to ask why notifications and service foreground state are coupled so in the API in the first place. [0] https://developer.android.com/reference/android/app/Service#stopForeground(int) https://developer.android.com/reference/android/app/Service#... [1] Control Coupling - https://en.wikipedia.org/wiki/Coupling_%28computer_programming%29#Procedural_programming https://en.wikipedia.org/wiki/Coupling_%28computer_programmi...

londons_explore 3y ago

The android codebase is so huge there is nobody who really has a good view at all of it to make architectural decisions. Also internal politics sometimes impacts technical decisions ("No, you can't add an API to our teams codebase - we're underresourced and don't have time to review your changes till Q4 2025"). End result: API's are added in silly places.

ykonstant 3y ago
On second thought, let's not go to Camelot.

cmrdporcupine 3y ago

My experience is that Google code reviews tend on the whole to get so caught up in stylistic and micro-level technical comments that overall design gets lost in the shuffle. Especially in something really large and old and evolved like Android or Chromium. In general the code review process can work at Google for most projects because the essential design questions are already set in stone. You use protobuf/gRPC, follow the patterns that other services have mandated. There is usually a "recipe." And within Google design problems are perhaps sometimes addressed during PRD/design-doc phase, in a big Google Doc. But not always. But I can see how this could completely fall over when these things go out into the external world. That and the need to make everything into small microlevel reviews that get nitpicked for days means that large wholesale architecture simplifications and refactors just don't really happen very often. Few projects have people with that kind of authority. The Torvalds review is pretty savage.