1. 19
  1.  

  2. 15

    I’ve had to do some Android dev recently, and it’s the worst development experience I’ve ever had. Everything about it is a mess.

    Basic development tasks (profiling, etc.) can’t be done without rooting your device and voiding the warranty. There are arbitrary changes to the tooling so often that any info on the web from 2017 or earlier is completely out of date and not applicable any more. If there’s a StackOverflow answer from 2013, the solution has probably changed 5 times since then, and the tools mentioned in the answer won’t even exist in the SDK/NDK any more. They took two industry standard tools (Linux, Java) and created a bastard child incompatible and different than both of them. It’s a disaster.

    And Android Studio is the worst. The UI is ugly and confusing with a million buttons and panels all over the place. The icons are meaningless and un-intuitive. Gradle is terrible. 32 Gb of RAM and an SSD, and it’s still slow and laggy. It’s horrible.

    Needless to say, I’m absolutely not surprised they’ve made another arbitrarily major change.

    1. 7

      Basic development tasks (profiling, etc.) can’t be done without rooting your device and voiding the warranty.

      Are you sure? I have profiled apps with my device that is not rooted perfectly fine. Not sure what other development tasks you are referring to that require your device to be rooted.

      I started mobile development for the first time last December, using Android Studio with Kotlin, and my experience has been almost completely the opposite of yours. Coming from primarily Python experience, I’ve really enjoyed learning Kotlin and using it daily – it solves a lot of the problems I had with Java, while being a touch more expressive than Python. I also don’t share your issues with Android Studio, perhaps since I’m coming from using PyCharm so I am already used to the Jetbrains IDEs. I use a laptop with 16GB RAM and haven’t had issues with slowness. I will admit that it is a resource hog though!

      I’m not trying to say your experience or opinions on it are “wrong.” I just wanted to share my experience with it as well, in case there are others that are thinking about trying it out.

      1. 5

        Are you sure? I have profiled apps with my device that is not rooted perfectly fine. Not sure what other development tasks you are referring to that require your device to be rooted.

        AFAICT there’s no way to use simpleperf or any other command line profilers without rooting the phone. I wouldn’t mind being proven wrong if anybody knows a way.

        And here’s another example I ran into the other day while trying to detect memory leaks in a native shared library.

        Here’s a SO question/answer from 2010 referencing DDMS, which doesn’t exist any more.

        The first answer now has a “2017 Update” saying to use Valgrind, and pointing here. But when you get there you’ll find out that Valgrind’s already deprecated (and removed from the NDK) in favor of LLVM’s ASAN, and it has a link to here.

        Note the first few paragraphs are about the new (as of Feb. 2019) HWAsan, so it’s already changed again.

        In any case, reading about software ASAN, you can see that using it requires copying ASAN enabled libraries into /system/lib/asan, which isn’t possible without rooting the phone. Profiling a single app requires running “adb root” and setting a “wrap” property, which also isn’t possible without rooting the phone.

        So I was stuck using the crappy memory profiler inside of Android Studio which doesn’t give any useful information about native objects except for the total size allocated.

        Straying back on topic, I don’t have an opinion on Kotlin. Our app is already written in Java and C++, and we don’t have any reason to change, and no time even if we wanted to. The syntax is nicer than Java, but that’s not saying much.

        1. 2

          I see. Based on your comment I thought you were saying you couldn’t profile at all without root. Makes sense! I understand your frustration. I must have just gotten lucky with what I was working on – most SO posts I ended up on would have a newer answer that was up to date with the now “proper” way to do something.

      2. 3

        Yeah, the last time I did any Android dev was Android 2, and it was just awful back then too. Good to know that things haven’t changed. It’s a shame too, because I’d love to write code that runs on my phone. But the development shenanigans are too much for me to push through in my leisure time.

      3. 3

        This about sums it up: https://wiki.debian.org/AndroidTools

        There does not seem to be a way for the Debian volunteers to keep up with properly packaging the Android SDK, not to mention NDK or however they are called now. That’s a clear enough sign to stay away from Android development if you want to remain sane.

        1. 3

          Anybody know why, if they were going to do something like that, why they didn’t bump to something like Clojure?

          Why Kotlin? It seems like a pretty much a why bother step.

          1. 11

            Using something like Kotlin gives you nice new language features without having to upgrade the JVM

            It’s also stupidly easy to port Java files to Kotlin

            I think Clojure would be interesting, but the tooling infrastructure is not great from my experience. There’s also all the startup time issues and the “Rich” issue (Google would either need to convince Hickley to allow for deeper collaboration or they would need to fork the language to be able to provide improvements)

            I also think that, institutionally, Google doesn’t have any functional programming chops? All the languages they use day to day are procedural, the APIs for libraries they generate are also this.

            1. 3

              think that, institutionally, Google doesn’t have any functional programming chops?

              I think that’s probably it.

              Their support for go is symptomatic.

              1. 1

                But they are announcing this to people outside the company to encourage them to use Kotlin? Not sure if we can infer anything about internal practices - the idea here is a better language “for the masses”, of whom may be more used to imperative programming

            2. 5

              kotlin is a nicely conservative set of extensions to java, and seems pretty tastefully designed. looking at it from the perspective of scala or clojure, it might seem barely different from java, but every feature they add makes a significant quality-of-life improvement for developers.

              for me the biggest selling point is that they have tried to minimise the code size and runtime overhead compared to java - i love clojure as a language, but if i had to do android development i would 100% choose kotlin for this feature alone. but also there are other features like not just easy java interop, but easy conversion of your java code incrementally to kotlin, excellent ide support from jetbrains, and a very easy learning curve for existing java developers (including ease of translating java-based android examples to kotlin).

              the only contemporaneous language i saw that was playing in roughly the same “java plus a few advanced features” space as kotlin was redhat’s ceylon, and that was already far less conservative. i do have some regret that nice never caught on; in a lot of ways it was targeting the same space as kotlin, and was well designed, but it had no large organisation behind it, and it lacked a killer application that would make people use it instead of java. kotlin seems to have come around at a time when people are ready to embrace it.

              1. 1

                the biggest selling point is that they have tried to minimise the code size and runtime overhead

                How did they do that (given that they’re on the same jvm)?

                1. 1

                  in large part by sticking close to java, i’d imagine. so idiomatic kotlin will have the same performance characteristics as idiomatic java, and you don’t need to load a bunch of extra code for the language runtime, or deal with conversions between each language’s notion of a native object, or load an entire separate stdlib.

              2. 3

                Probably because developers used to Java and other procedural/OO languages have an easy time moving to Kotlin but a harder time moving to Clojure.

                1. 3

                  Actually in terms of changing syntax… nothing is easier than moving to a lispy language….

                  Everything is just (function-name arg arg arg…)

                  Done.

                  You know the syntax now. ;-)

                  It’s the semantics that gets interesting and clojure’s semantics have some extraordinary simplifiers.

                  1. 1

                    Simplicity is a killer once you’ve learned the complex (familiar) way though. You could just as easily vouch for assembly. At the end of the day I know how to do for loops with the for keyword, not with tail recursion or branch jumping or any other new way. It’s the same reason why “Hello World” examples for new languages and frameworks are useless. Yes, I’m sure this new tool is fantastic at printing text to my screen, but I need to use it to build an API with a dozen different endpoints and database interfaces and I have no clue if this thing can do that.

                    I really love lisp, but it’s a hard sell to anyone who’s done imperative programming before and has a deadline to meet. “Why fix what’s not broken?”

                    1. 2

                      You could just as easily vouch for assembly.

                      Assembly is nowhere near as easy as the command example he just gave for Lisp. Its complexity, verbosity, and tedium are among the reasons people who know Lisp and are bootstrapping write a Lisp as quickly as possible, then do the rest in Lisp. It’s easier. Also, more powerful in terms of code size vs ideas expressed.

                      You’re right about familiarity, though. That always helps pull folks into new languages. Lisp is also hard to sell. I wouldn’t push it for Java replacement on Android. I thought they were going to use Go.

                2. 3

                  If you know about clojure runtime characteristics you would know why it wouldn’t be a good choice for android.

                  1. 2

                    It’s say that at least in part it’s because of the syntactic similarity to swift, plus the plans to make kotlin/native a proper cross platform option (which is wasn’t, last time I checked).