For example, I once wasted two days getting an app startup logo to show with the proper size and aspect ratio on versions of Android used on phones sold 4 years ago, through the latest version. You define the logo in the manifest file. The interpretation of the logo settings changed three times over those API versions, with features added and removed. So a config that works in Android API 18 doesn't work in 20-21, but may work on 23. Support for SVG was dropped and added again. And none of this is documented. The logical way to implement API changes is to version the API file and use a compatibility library that can interpret all supported versions and make them work on the phone. But Android is not built logically. It is built for Google's engineer promo process.
Nobody at Google gets promoted for making the thing easy to use, learn, or maintain. That's why Google puts out so many shiny dev tools that quickly rot. Unfortunately, we are required to work with Android.
I had a similar experience with scalable graphics and having to support anything from Android 4 (can't remember if .2 or .4) to Android 8. It feels like programming in JavaScript and trying to support anything from IE 8 to the latest Chrome, Android is full of polyfills and helper libraries whose only purpose is to fill in the gaps for missing, replaced or removed functionality.
wouldnt you just build different binaries for different versions of android you want to support? Why is it even a requirement that one binary works on all versions?
You can just gate the upgrade of the app, so that customers on the older version can't upgrade.
As an Android developer on apparently one of the N biggest apps there are, lots of hard truths but also lots of 'I like things this way so I don't think things any other way is fine'. It's problematic and in an ideal world we could do so much better, but as they mentioned, there's a lot of cruft and backwards compatibility. Have you tried writing a Win32 app?
---
AndroidManifest.xml vs code declared, the manifest in reality is very different. An "app name" isn't really something useful programmatically. Orientation can be handled programmatically, but you can declare app-wide support for what kind of orientation you support in the manifest.
One syntax is really a style preference. I don't mind using different tools for different tasks, and the manifest is very specific to a specification for the app store, not on-device.
Java vs C++, meh, I think the main idea is that Java is a better language for most people than C++. Especially whatever C++ version existed when Android first came out.
Low-power is kind of a bad argument and pre-mature optimization without real metrics. It's been pretty clear that the reason phones drain the battery is because of the screen, and background jobs hogging the CPU, not running the JVM. Maybe running some compiled binaries would be more performant, but laptop batteries kind of also suck.
Keyboards, yeah, a bit weird, but the idea is that you almost never need to interact with the keyboard, you interact with elements that the keyboard injects into, since people can swap and use custom keyboards and other ways to enter text like dictation or accessibility modes.
Very true that all of this is not newbie friendly though. Shockingly bad really. Especially the status bar APIs.
Save State and process death is also a hilarious one that's underdocumented and confusing to new (and experienced) developers alike.
Its not an argument of Java vs C++, its a platform trying to force their language of choice on to everyone, thinking existing code, experience, and workflows doesn't matter.
I used to enjoy Android about 6-7 years ago. Had a handful of small apps I was proud of.
But god forbid you step away for 6 to 12 months -- rebuilding my once happy app becomes literally the only thing I'll be blowing a day on getting to work again.
Often times I'll just say fuck it and reinstall Android Studio from scratch.
The joy of it all is gone for me.
And then on top of all that, you never know when Google will decide your app (that's been on the Play store for years) is suddenly in violation of SOMETHING and pulls the plug without an explanation, ignoring appeals. (Had this happen to me a couple times.)
With no interest in iOS, and no real alternatives, all that adds up to me eventually retiring from mobile dev in general. Dammed shame, because I had some fun for a while.
Even if your app is very simple, you constantly need to do something to keep it on the app store. Agree to this, add that type of image, fill that sort of info. It gets tedious.
IMHO most problems (apart from the missing C APIs) of the Android NDK could be fixed if they'd steal a few ideas from the emscripten SDK.
In emscripten I can do:
emcc hello.c -o hello.html
...and this gives me a complete 'web application' ready to run in the browser.
With the Android NDK I should be able to do this:
ndkcc hello.c -o hello.apk
...and this should give me a complete APK ready to run on the device. Emscripten's emcc is just a "simple" python wrapper script which looks like a gcc-compatible compiler/linker from the outside, but does additional things besides calling the C/C++ compiler and linker (such as creating a .js and .html file next to the .wasm compiler output).
If the NDK would have such a compiler wrapper script it would be absolutely trivial to integrate with any existing C/C++ build system.
Another idea the Android NDK should steal from Emscripten is how to integrate the C/C++ side with the "other" side (in Emscripten's case Javascript, and in the NDK's case Java). In Emscripten I can simply embed Javascript code into the C source files with some macro-magic, and call back and forth directly between C and JS. This is how the Java integration should work in the NDK. I shouldn't have to deal with the JNI or with the Java toolchain or with .java files at all.
I disagree on the part about manifests. Having a manifest file containing device compatibility and permission information that can be read without executing your app is critical for e.g. app stores.
The manifest file could be generated at build time.
I believe it's more developer-friendly in the long run to be able to do configuration from in-band in the same language / environment the application is running in vs out-of-band config. Spring config has become a good bit more manageable now that it's in doable Java (or Kotlin) rather than only XML.
Both in-band and out of band could be offered, it wouldn't have to be a hard cutover anyway.
And particularly the complaint from the thread that focuses on "program name, orientation handling, icon, permissions"... these are all things that are always done as part of separate languages if not separate files (whether it be .rc files on Windows or Info.plist files and plist entitlements on iOS/macOS).
The actual icon pixel data must exist as a resource though and not as (for instance) a C array of RGBA values (which sort of makes sense because Explorer must also be able to access the icon). I guess that's also the reason why those things are in manifest files on Android (and I think iOS too): they must be accessible from the outside without running the program.
I 100% agree that Android is by far the worst platform to develop for though, at least when it comes to native code.
Why is there an assumption that I'm going to distribute my program using an app store? Why is there a assumption that all app stores want the same information in the same format? Submission should be a completely separate process from software development.
FWIW pretty much all platforms have switched to manifest files now, even Windows (they're just not mandatory). For Android I simply create a dummy manifest file during the build process, along with the whole APK packaging and code-signing with a debug certificate. This might help if you want to try ditching Gradle, it's essentially the "missing link" to put the whole build process into cmake (or similar C/C++ build tools):
It's really to tell the OS's package manager at install time what the entry points are and what device capabilities are required. The fact that app stores can also parse that information out is a convenient side benefit.
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.
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. :-)
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 ;)
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.
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.
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.
Documentation is a big pain point for many of the big platforms for me. Be it Android or iOS.
On the Android side it seems like there was a huge push for documentation some years ago but due to the sheer size and scope it seems like many things just never got updated and new things got the "Gotta go Fast" treatment. It's always very frustrating reading an official "How-to" article telling you to do one thing and when you click through to the underlying system's documentation you notice that this is no longer how you do it.
On the iOS side I can't understand how anyone figures out how things work. Maybe veterans know enough to decipher 4 word descriptions of a function argument and a random list of exposed function names but I certainly can't. e.g. How anyone figured out how ReplayKit works from the "docs" is beyond me. There is a WWDC video and hopefully some sample code you find in some repos but good luck with that...
I can forgive a lot of peculiarities of a system if I can at least figure out the what & how in the documentation/guides.
There are documentations for rather complex systems that I thought were absolutely amazing, e.g. the MS Hololens. So it is at least possible.
Agree entirely - Android is an appalling environment for programming, or for using a computer. It shows an almost complete lack of thought and consideration.
I resorted to the "graphical language" MIT App Inventor. App Inventor might be clumsy and awkward, but nothing is as bad the Android environment and "tool set".
You should try the iOS development platform. You can't even run other apps except the app you are building on the emulator (I needed to test my mobile app launching another app feature) not to mention that you are pretty much fucked if a part of the SDK breaks (versus for Android when it's just an open source patch)
I can confirm this, I’m still waiting for Apple to patch sign in with apple on simulators, where you can’t sign in at all or sign in periodically breaks. It’s been like this since the xcode 12 beta. Regardless I still feel its a far better experience than developing for Android.
>Regardless I still feel its a far better experience than developing for Android.
How so? I enjoy that on Android at least I can fix things manually or some open source contributor will soon jump on it to fix it for me. You have to wait for Apple to fix things.
Android is open-source but large parts of it aren't - for example, the google play services libs.
The open parts can take literal years to get a fix merged and deployed, so "some open source contributor fixing it" happens very rarely and isn't something you can rely on. Even when that happens, if the bug was in the core SDK instead of in one of the support libs, you'd have to wait like 5 years until most users get the fixed version of the code on their devices.
"Installing a development environment and connecting it to a device is a mess of broken links, poor integration and company turf wars. I managed to get a working environment on the third computer I did a clean install on."
Hmm different people, different experiences.
I work as an Android developer, an in general debugging on the devices works easily.
Android Studio works fine with my testing devices: Samsung, Xiaomi, Pixel, both on Windows and Mac machines. Just plug the device and Android Studio will automatically detect it.
Probably the last time debugging on the device didn't work was when I had a Nokia (6??). No matter what driver I installed, Android Studio didn't detect it. I gave up.
If instead ranting on twitter, he actually bothered to learned, it would have found out that virtual machine is long gone and now a mix of JIT/AOT compilers are used.
Also not allowing full blow applications in C or C++ is exactly the kind of stuff we need to move the security of our devices forward into the future.
While Android development has several issues, these random rants aren't it.
I've had to program some Android apps in the past, mostly internal or technical tools for scientific applications. Last time it was last year, and after struggling for a week to get old code run reliably using the latest SDK, I gave up and rewrote successfully the app with Qt and the NDK. Is this a viable solution for something that can be offered through the Google play store?
PS If any Apple fanboys want to use the above rant as proof for why iOS is better, you should be careful not to tempt me in to putting in to words my feelings about iOS, because you may not like what i have to say.
I'm intrigued; please do! (I'm an iOS developer... and definitely not a fanboy.)
Android development: API has a bizarre malfunction. You hunt around the exact source version to find an obscure workaround, which might work or not. Most likely you are screwed. Plus there will definitely be one phone model, were you are definitely screwed.
iOS development: API has a bizarre malfunction. You are screwed.
Both: You have a bug free app. Until 3 years later, when half the stuff you used is suddenly broken in the OS, the other half is deprecated.
ah the old "I don't know anything about this implementation and why things are made this way but I would have made it 10 times better with half the resources".
Kinda... developing UIs is around 10x easier and faster, but you can get in trouble when you want to integrate with device APIs like Camera, Location, etc.
You also don't have such a rich ecosystem of third party libraries. For example, I think there's still no implementation of native ads for major ad networks, which can be a deal-breaker if you're working on a large consumer-facing app.
Regarding native C/C++ interop (thank God I no longer have to deal with this!), Flutter has dart:ffi. I'm not sure how it compares to JNI, but it can't be worse. In practice, you'd still end up dealing with the horrible NDK toolchain on Android, though.
In my opinion: yes it does, Flutter exposes many "High level" il APIs over Android and iphone and evrything seems to be easier. However sometimes you still need to know how the Android/iOS implementations to fix bugs and understand how things work.
I'm an Android Developer and I've found Flutter to be a pleasure most of the time.
For example, I once wasted two days getting an app startup logo to show with the proper size and aspect ratio on versions of Android used on phones sold 4 years ago, through the latest version. You define the logo in the manifest file. The interpretation of the logo settings changed three times over those API versions, with features added and removed. So a config that works in Android API 18 doesn't work in 20-21, but may work on 23. Support for SVG was dropped and added again. And none of this is documented. The logical way to implement API changes is to version the API file and use a compatibility library that can interpret all supported versions and make them work on the phone. But Android is not built logically. It is built for Google's engineer promo process.
Nobody at Google gets promoted for making the thing easy to use, learn, or maintain. That's why Google puts out so many shiny dev tools that quickly rot. Unfortunately, we are required to work with Android.