4 ms·

"[Android] development tools are focussed on large teams of highly trained software engineers, who all intimately understand every esoteric aspect of App develo

by McDev 6y ago

"[Android] development tools are focussed on large teams of highly trained software engineers, who all intimately understand every esoteric aspect of App development." This really rings true to me. I almost cringe when I have to explain how to do some of the most basic things to non android developers. Aside from the dozens of libraries you need to include, and need to know where to find and what version is compatible with what, the tooling itself is an insurmountable mess for new developers. It's also not getting any simpler.

skohan 6y ago
I have to admit I often roll my eyes at the state of mobile development, especially on Android. I worked on a few Android apps in 2009-2012 when a "best practice" hadn't really been established yet, and as I tangentially follow the field now it's hard to understand how insanely complicated it's all become. I mean literally for 90% of apps we're talking about doing some REST requests and populating some text and images on screen. Why dozens of libraries are needed to achieve this I cannot understand. Like I was interviewing a guy for an Android role, and he was walking me through a pet project of his which consisted of literally one list view which updated it's contents to filter results out of an SQLite database as you type into a text field, and the project had literally dozens of files. It just made me sad. I mean maybe there is something I don't understand, but the state of the field seems to be heavily driven by following what the "cool kids" are doing, and the tooling seems to have more to do with signaling that you're in the in-crowd than it has to do with actually delivering value.
- ohgodplsno 6y ago
  >Like I was interviewing a guy for an Android role, and he was walking me through a pet project of his which consisted of literally one list view which updated it's contents to filter results out of an SQLite database as you type into a text field, and the project had literally dozens of files. It just made me sad. That's most likely overengineering. The only things you need for this are: - An Activity - Eventually, a Fragment, but you can do your work in the activity directly - A database, optionally in another file to abstract out direct queries, but it can simply be direct SupportSQLite queries. Just, not on the main thread. - A viewmodel if you don't want to hate yourself and write logic in your Activity, making it basically untestable. - A layout file for your activity/fragment. - A layout file for your recyclerview list element That's 5 files. 6 if you include build.gradle, 7 with AndroidManifest.xml This can all be written in under 500 total lines. Library wise, all you need for that is androidx and recyclerview.
  - arexxbifs 6y ago
    I honestly can't tell if this is a joke? 0.5 KLOC. Seven files. That's not over-engineered?
    - deleted 6y ago
      [deleted]
    - ohgodplsno 6y ago
      A lot of that is due some Android APIs being insane. Amongst all of those, the RecyclerView adapter will be over a hundred, because it is a stupidly verbose API. Layouts are XML, so, yeah, stupidly large too. Those two contribute to a lot of those lines. Not so much overengineered as lol-google-apis engineered. ViewModels are also due to the batshit insane android lifecycle, where you can easily be bitten in the ass. All of those are not for fun. They're because the Android APIs are terribly crap, or because you're not allowed to do certain things on the main thread (like, say, database queries) After that, you can very well put your activity/fragment/database logic in the same file, if you know you're never going to maintain it.
      - Larrikin 6y ago
        No matter how many times I write a recyclerview, which is usually atleast one for any new screen, it never stops being the worst part of Android dev for me.
      - m_fayer 6y ago
        I used to say it a lot. It's been a long time now, but heck for old time's sake: how I miss Windows Phone.
      - noema 6y ago
        "Best practice Android development" is soon to phase out XML (for the most part) with Jetpack Compose. Working with two way data binding in XML seemed like a good idea, until you had to debug it.
        6y ago
- 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 ago
    That, 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 ago
    I 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.
FpUser 6y ago
I once did small project for Android (basically created a library that would receive stream of data over BlueTooth from some device). Setting up the development environment (I've created full system backup prior to installation) and then using it made me hope that it is the first and last time I touch this pile of s... .
quaa55 6y ago
what about flutter?
- entha_saava 6y ago
  I tried flutter and while it seems better than Android studio, it has its own problems. I precached but it still required internet access to get some maven deps for android build. Updating is full of hassles and gradle, as always, unexpectedly fails somewhere eg in "assembleDebug" step. Maybe some version mismatch and I am not in a situation to do clean installs that require GiBs of internet. And no guarantee it works even on clean install. I have come to a conclusion that front end (web or app development) is a mess and it is not for me. Look at Go, or Rust to know how to keep tooling simple and straightforward.

by McDev 6y ago

skohan 6y ago

I have to admit I often roll my eyes at the state of mobile development, especially on Android. I worked on a few Android apps in 2009-2012 when a "best practice" hadn't really been established yet, and as I tangentially follow the field now it's hard to understand how insanely complicated it's all become. I mean literally for 90% of apps we're talking about doing some REST requests and populating some text and images on screen. Why dozens of libraries are needed to achieve this I cannot understand. Like I was interviewing a guy for an Android role, and he was walking me through a pet project of his which consisted of literally one list view which updated it's contents to filter results out of an SQLite database as you type into a text field, and the project had literally dozens of files. It just made me sad. I mean maybe there is something I don't understand, but the state of the field seems to be heavily driven by following what the "cool kids" are doing, and the tooling seems to have more to do with signaling that you're in the in-crowd than it has to do with actually delivering value.

ohgodplsno 6y ago
>Like I was interviewing a guy for an Android role, and he was walking me through a pet project of his which consisted of literally one list view which updated it's contents to filter results out of an SQLite database as you type into a text field, and the project had literally dozens of files. It just made me sad. That's most likely overengineering. The only things you need for this are: - An Activity - Eventually, a Fragment, but you can do your work in the activity directly - A database, optionally in another file to abstract out direct queries, but it can simply be direct SupportSQLite queries. Just, not on the main thread. - A viewmodel if you don't want to hate yourself and write logic in your Activity, making it basically untestable. - A layout file for your activity/fragment. - A layout file for your recyclerview list element That's 5 files. 6 if you include build.gradle, 7 with AndroidManifest.xml This can all be written in under 500 total lines. Library wise, all you need for that is androidx and recyclerview.
- arexxbifs 6y ago
  I honestly can't tell if this is a joke? 0.5 KLOC. Seven files. That's not over-engineered?
  - deleted 6y ago
    [deleted]
  - ohgodplsno 6y ago
    A lot of that is due some Android APIs being insane. Amongst all of those, the RecyclerView adapter will be over a hundred, because it is a stupidly verbose API. Layouts are XML, so, yeah, stupidly large too. Those two contribute to a lot of those lines. Not so much overengineered as lol-google-apis engineered. ViewModels are also due to the batshit insane android lifecycle, where you can easily be bitten in the ass. All of those are not for fun. They're because the Android APIs are terribly crap, or because you're not allowed to do certain things on the main thread (like, say, database queries) After that, you can very well put your activity/fragment/database logic in the same file, if you know you're never going to maintain it.
    - Larrikin 6y ago
      No matter how many times I write a recyclerview, which is usually atleast one for any new screen, it never stops being the worst part of Android dev for me.
    - m_fayer 6y ago
      I used to say it a lot. It's been a long time now, but heck for old time's sake: how I miss Windows Phone.
    - noema 6y ago
      "Best practice Android development" is soon to phase out XML (for the most part) with Jetpack Compose. Working with two way data binding in XML seemed like a good idea, until you had to debug it.
      - 6y ago
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 ago
  That, 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 ago
  I 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.

FpUser 6y ago

I once did small project for Android (basically created a library that would receive stream of data over BlueTooth from some device). Setting up the development environment (I've created full system backup prior to installation) and then using it made me hope that it is the first and last time I touch this pile of s... .

quaa55 6y ago

what about flutter?

entha_saava 6y ago
I tried flutter and while it seems better than Android studio, it has its own problems. I precached but it still required internet access to get some maven deps for android build. Updating is full of hassles and gradle, as always, unexpectedly fails somewhere eg in "assembleDebug" step. Maybe some version mismatch and I am not in a situation to do clean installs that require GiBs of internet. And no guarantee it works even on clean install. I have come to a conclusion that front end (web or app development) is a mess and it is not for me. Look at Go, or Rust to know how to keep tooling simple and straightforward.