Ask HN: Am I crazy or is Android development awful?

Lmao, tbh all this is coming across as "Jr Engineer knows everything" syndrome.

The fact your [1] link is a class that's not even used in the TextView class isn't lost on me to start. They share an interface though, scary!1!!

The fact your [0] link is to a copy of the TextView from 2017 is even funnier.

> Just look at the sourcecode for TextView[0] if you want to see for yourself. 8,700 lines of code to show text on the screen? Well actually, TextView is actually a full blown text editor with the editing functionality turned off as a flag.

Hmm yes, 8,700 lines to "just show text". No hyperbole detected there. Who cares about fonts, shadows, or any other visuals on or around the text, all we're showing is "just text".

> Well actually, TextView is actually a full blown text editor with the editing functionality turned off as a flag.

And? It's called code de-duplication. While realistically I think the better approach would have been to have TextEdit be the barebones display only and Editor add the editing functionality, sometimes code is so tightly coupled for reasons that you can't do that easily. This approach is much better than hitting cmd+c/cmd+v and copying the code into a new class.

The funniest part to me is that your rant is about TextViews though. When that's been soft deprecated for 5 years already (replaced by Compose Text element).

I will also say: Android Kotlin and pure server Kotlin are entirely different beasts. If you are on Android and you are frustrated with Kotlin, it is probably Android.

Kotlin compiles now to JS, WASM... even LLVM bitcode if you want it to. Coming to Kotlin from a pure lang perspective, I'm not sure what it would be like, it might not be you. I know as someone who came to it through Java that it is a massive improvement on what I had before.

Not only is Android a mess but the Google Play Store is terrible too. There's now this insane requirement that devs have to find 20 testers on their own for two weeks before publishing anything and, incredibly, the Play Store review process is also qualitatively slower and worse than Apple's.

I think we're going to see the tendency accelerate to develop and validate ideas on iOS first and only later outsource a crappy Android port.

Android development is Kotlin. Sometimes C++, but I've never seen or worked on a project that needed it. Using any other language will be an uphill battle that will make your life harder.

OpenCV also has a warning and a guide for people trying to use it for Android dev https://opencv.org/android/. Did you look through this?

Also why do you want to use a USB camera when every phone has a couple cameras built in? I think you're going down a road of frustration if you think mobile OSes aren't built with completely different use cases in mind than desktop environments.

Theres a lot of information the Android dev site about getting up and running with the camera. You can pass a lot of the photo stuff off to other camera apps on your phone, but if you really need to do stuff in the app theres an official Android library for making your life easier. Theres also a lot of official Android libraries and well known libraries for images and videos that might be easier to work with than OpenCV. You don't actually say what you are trying to ultimately do.

Gradle is the part of Android dev everyone hates.

>The fact your [1] link is a class that's not even used in the TextView class

The [1] link is only used by TextView. It is completely reliant on TextView and can't be used by other components. And yes, it is used, right here: https://android.googlesource.com/platform/frameworks/base/+/... mEditor is used over 400 times in TextView.java. Did you even read it before commenting?

>The fact your [0] link is to a copy of the TextView from 2017 is even funnier.

Why is that funny? Most of it has not changed. I linked to the up to date one in the second link. I searched "TextView source code" on Google to get the first one. It gets the point across and doesn't matter how old it is.

>Hmm yes, 8,700 lines to "just show text". No hyperbole detected there. Who cares about fonts, shadows, or any other visuals on or around the text, all we're showing is "just text".

I'm pretty sure a lot of that is handled by DynamicLayout, not TextView, although correct me if I'm wrong here. If if it isn't, it should be, and is indicative of poor software design. Shadows certainly should not be handled by TextView, I have no idea why anyone would think that.

Take a look at Flutter's implementation. Text is just 1,400 lines, a large portion of which is documentation (another thing the Adnroid SDK sorely lacks,) and it just shows text to the user.[0] Somehow all the "tight coupling" issues have gone away here, and there is no need to throw a text editor into the code. How does Flutter edit text? It has a base EditableText class[1] that is then exposed by simpler widgets like TextField[2]. Now if I want to make my own custom editable text I can without having to recreate the whole thing.

>And? It's called code de-duplication

No. You don't get rid of separation of concerns to save a few bytes. If TextView cannot be made into a separate component that EditText uses then it should implement the functionality of TextView on its own. This is called the single-responsibility principle. A TextView should not be a texteditor. It can't get any simpler than that. Either refactor the text viewing components into something that can be shared by TextView and EditText, or separate them completely.

>The funniest part to me is that your rant is about TextViews though. When that's been soft deprecated for 5 years already (replaced by Compose Text element).

I wonder why this great piece of code was deprecated if it's so great? And yes, that's another great thing about the Andorid SDK. Everything is deprecated while its replacements are only supported on new devices. Then you end up having to do:

if(onReallyOldDevice){

   useDeprecatedMethod1()

}else if (onOldDevice){

   useDeprecatedMethod2()
  

}else{

   useSoonToBeDeprecatedMethod()

}

See eg. accessing file systems.

[0] https://github.com/flutter/flutter/blob/master/packages/flut...

[1] https://github.com/flutter/flutter/blob/master/packages/flut...

[2] https://github.com/flutter/flutter/blob/master/packages/flut...