Hacker News Reader

Comment by ryan-duve | Hacker News Reader

I only know how to program "computer"-computer apps in Python and C (and some web stuff). Could someone explain exactly what's so bad about developing for Android using only words someone who doesn't know Java would know? Apologies if I should know who Eskil Steenberg is ahead of time.

Naively, I would guess there's a bunch of free libraries you have to import provided by Google or whoever owns Android, and those expose things like `AppWindow()` and `Input()` and `Camera()`. Am I even close? Is this nothing like what one actually does to make an Android app? Is iOS somehow better?

I have no reason to make an app, but I'm considering just looking for a "Hello world!" tutorial and following through just to understand what makes it so notoriously challenging.

View on HN

The problem is that all that skill and know-how you have about how to program a computer is invalid on Android. Your assumptions about what you should expect to find in the android API is entirely valid. You should find Input(), Camera() or similar. But you dont. Almost everything is different, worse, more complicated and not documented.

You think you can depend on basic stuff like fopen, but it doesn't work like you expect it to. Its a minefield.

If you are trying to make some simple "hello world" application its incredibly infuriating, because what should be simple is made so hard, not least by the platform keeps insisting that "you really should learn this other language"

And for the record: You should not know who Eskil Steenberg is ahead of time, but you are welcome to get to know me now. :-)

Eskil Steenberg

IMHO the Android NDK is exactly what one might expect when Java people are trying to build a C SDK. You can physically feel their disgust pouring out of the screen ;)

Thats both great and hilarious that you showed up to answer in person. Nice work!

fopen doesn't work like you expect?!?

fopen() worked. It's just no files are bundled as-is in an APK. Files must be embedded into a resource-like asset file which could not be opened by fopen(). If a library your app linked to had to call fopen() and other POSIX file APIs for these files, you were f*cked up and ended up unzipping files.

Hi Eskil! Would love to hear your thoughts(rants?) on iOS too :)

My experience, i don't program java, i learned there was a way to compile dlang apps for android. Download android sdk, download android ndk, try and build program to no avail. Study android sdk and ndk, realize it's probably not worth the effort without learning java. Play around with the android scripting layer and termux get disheartened at the lack of actual lower level device access. Go back to programming things for actual computers.

Um, I'll try:

So it's really the same as a "computer-computer", but with a specific UI framework and peripherals like a compass, GPS, camera (as you mentioned), etc.

Where it starts to suck is the interface for interacting with all those things: So you want to access your device's location? Well do you want to use the cellular/WiFi network, GPS, or both to tell you where you are? Ok, you figured that out, now how fast do you want updates? Oh, that was more of a suggestion - what's the fastest we can send you updates? And so on.

And it's like that for almost EVERY. SINGLE. THING. Imagine someone sat down to develop a mobile API, then got bored halfway through and decided to just leave the rest as an exercise to the user. And then some other people decided to come along later and add "improvements" (i.e: what Apple is doing) to the mishmash of existing "stuff", and you basically get Android development.

Yes, iOS is better, at least in my opinion. It's hard to pin down, but you get the sense that at least they designed it for someone who actually wants to write an app.

> Where it starts to suck is the interface for interacting with all those things: So you want to access your device's location? Well do you want to use the cellular/WiFi network, GPS, or both to tell you where you are? Ok, you figured that out, now how fast do you want updates? Oh, that was more of a suggestion - what's the fastest we can send you updates? And so on.

Given its a mobile device with battery limitations, those seem to be reasonable inputs to want for an API?

My issue is more the amount of "knobs" you're presented with that seem to have overlapping responsibility. It's very difficult to figure out which ones are "right" (idiomatic?) so it makes for a very confusing implementation. Compared with iOS which gives you many of the same controls but at least presents them in a clear, unified way.

Ah, I think I understand now. It's more of a death-by-a-thousand-cuts than one-big-immovable-blocker that makes it hard to get stuff one. I've experience this with other frameworks and your description illustrates familiar difficulties.

I am no longer curious about making an Android app to better understand the headaches. Thanks for saving me from that :-)

Well I hope I didn't dissuade you from making an Android app at all! I've always hated the steady stream of discouragement that comes out of people who claim to "know better" and I'd certainly hate to have added to the pile. I'm just venting my frustrations after having developed a decently complex Android app for the past 1.5 years or so.

Reply on news.ycombinator.com