Hacker News Reader

Comment by Varriount | Hacker News Reader

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

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.

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.

The user-visible API's aren't great, but okayish.

The innards are spaghetti.

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.

During the early days Android APIs were clearly written by C folks with zero experience in Java programming culture.

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.)

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.

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.

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.

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.

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.

That's a really good point but thinking about it that way brings the decision to use Java at all into question. Clearly iOS/iPhones did great with ObjC in the same era.

The notification API has changed so much that it requires a Google compatibility library to target more than one Android version.

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).

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#... [1] Control Coupling - https://en.wikipedia.org/wiki/Coupling_%28computer_programmi...

Reply on news.ycombinator.com