3 ms·
With Android, part of the problem is that a solid ~80% of the "how to" information out there (and a distressingly high percentage of the official documentation)
by 0xcde4c3db 6y ago
With Android, part of the problem is that a solid ~80% of the "how to" information out there (and a distressingly high percentage of the official documentation) tells you to use things that were either deprecated years ago or are about to be deprecated in the next version of Android. Since the framework has gone through multiple iterations of this dance, you basically need to learn the whole history of any API you're using before you can decide how some part of your app is going to work.
Or you can pull in a library that seems to be popular and maintained and solves the problem that you have.
- karatestomp 6y agoThat, and there's a lot of "folk knowledge" around how to do things that the docs ignore. The cleanest and most efficient (or even just non-broken) way to do even basic shit is often to ignore how the docs say to do it and use some library. The whole platform feels badly neglected, like the only time anyone gives it serious attention is to throw some half-implemented shiny feature on top so they can announce it at an event, then never touch it again.
- mook 6y agoI think a large part is that the first-party documentation is pretty bad. My only exposure to the Android toolchain has been writing my own toy application, and it's just sad that the docs are terrible. Things like "this thing that used to be in the platform API had been replaced by that thing in appcomapt" → "nope it's in androidx now" → "this replaces that thing in the platform API, go read the docs for that instead". Essentially, you _have_ to read deprecated documentation to do anything… At least it's better than some other ecosystems, where it's "this thing is deprecated now. Nothing replaces it and you can't do similar functionality any other way, it's just deprecated." Or maybe I just haven't gotten to that part yet.