Why is Android Development so difficult/complex? (compared to Web and Desktop)

34 点作者 pyeri11 个月前

This is as much a philosophical question as it's a pragmatic one. I've developed all kinds of apps in my life including Visual Basic GUI programs, Windows Forms Apps with Visual Studio, web apps using PHP and Flask, console scripts in bash, python, etc.In terms of layers of complexity, none of that experience even comes close to Android Development though. To be honest, even Swing GUI in Netbeans/Eclipse wasn't that byzantine! (in fairness, I hardly ever went beyond Hello World there). To begin with, we are absolutely married to the Android Studio IDE and even though developing a project without AS is theoretically possible, the number of hooves you must jump though are probably too many for the average programmer to comprehend. Honestly, I still don't know how exactly the actual APK/AAB is built or compiled!On other systems, compilation is a straightforward process like `gcc hello.c` or `javac Hello.java`, maybe a few extra parameters for classpath and jar libs for a GUI app but to be absolutely dependent on an IDE and gradle packaging system just to come up with a hello world APK? Don't you think there is an anti-pattern or at least some element of cruft here?I get that Android operating system itself is highly complex due to the very nature of a smartphone device, things like Activities and Services aren't as straightforward as GUI Forms. But the point is that Android programming doesn't have to be that complex! Don't you think so?

14 条评论

remram11 个月前

I wrote apps for Android when I first got a smartphone, circa 2011, and it was so easy. There was a bit of doc to read to understand activities and intents but that was basically it. At that point you could write an app without running into new surprises.I tried again to write a tiny Android app last year and couldn't figure it out. There's so many moving parts with SDKs, API levels, support libraries, contexts, fragments, Gradle, ... And the documentation is built similarly, bolting on new chapters when new concepts are introduced, making a whole that is useless and inscrutable.It's really a shame. Is there a better starting point that could get someone ready to write a simple app in 2024? Some document that would introduce some reasonable workflow from A to Z (whether SDK, React Native, Kotlin, or whatever is simple)?

评论 #40745013 未加载

评论 #40746493 未加载

评论 #40746651 未加载

Kipt_11 个月前

I can't theorize on the 'Why' part of your question, but there are ways around using Android Studio IDE to make Android builds without gradle build system.If you want to learn exactly how the APK/AAB is built and compiled, here are some resources I used to learn:- <a href="https://stackoverflow.com/questions/59504840/create-jni-ndk-apk-only-command-line-without-gradle-ant-or-cmake/59533703#59533703" rel="nofollow">https://stackoverflow.com/questions/59504840/create-jni-ndk-...</a>- <a href="https://stackoverflow.com/questions/69566622/android-build-with-command-line-tools" rel="nofollow">https://stackoverflow.com/questions/69566622/android-build-w...</a>- <a href="https://github.com/HemanthJabalpuri/AndroidExplorer/blob/master/build_new.sh">https://github.com/HemanthJabalpuri/AndroidExplorer/blob/mas...</a>- <a href="https://developer.android.com/tools" rel="nofollow">https://developer.android.com/tools</a>Some of the links haven't aged too well, but it's a starting point for learning how things work under the "Android Studio" / "gradle" hood.

sxp11 个月前

Context: I developed Android professionally apps at Google & FB from 2010-2021/ and as a hobby dev during that time.I personally blame gradle for the complexity. It's such a horrible system for builds, and when I was developing Android apps on my own, I would avoid it at all costs. Using buck/bazel/blaze resulted in a much cleaner build process. It's been a while since I've wrote Android apps, but I've included a minimalist BUCK build file with Java + C++ components below. Note how it just has two build rules for the Java and cpp code. And it only requires 5 for a minimal Java/cpp app. If it was a pure Java app, it would just require the one build rule alone with a .java file and an AndroidManifest.xml.At the same time, I needed to maintain a public facing SDK so I needed to learn gradle which was an absolute nightmare. I spent way too much time reading docs on the build system compared to doing something useful with it.I'm not sure what the current state of the ecosystem is with Kotlin and modern Android Studio, but if I had to develop Android apps on my own again, I would start with bazel or buck for anything that's more than a Hello World template. I would recommend the same for anyone just starting out with Android development who is familiar with CLI-based development. One useful learning experience was to unzip an APK and figure out the individual build steps that converted a set of source files into the final APK. With bazel/buck, you can give it an option that causes it to print every build step which involves the build system calling Android SDK build tools on source files. Then you can manually run this commands yourself to see what they do. Doing this will tremendously help you debug any build issues and teach you how to remove bloated items from your build process.<a href="https://medium.com/androiddevnotes/the-internals-of-android-apk-build-process-article-5b68c385fb20" rel="nofollow">https://medium.com/androiddevnotes/the-internals-of-android-...</a> is a good starting point. In particular, read the section about "Understanding each part of the process" until you understand exactly what each box in that diagram represents.<pre><code> android_binary( name = "one", srcs = ["TestOneActivity.java"], custom_package = "me.sxp.test.one", manifest = "AndroidManifest.xml", deps = [":libone"], ) cc_library( name = "libone", srcs = [ "jni.cpp", "testonelib.cpp", "testonelib.h", ], )</code></pre>

joe_fishfish11 个月前

Couldn’t agree less. I’ve been a developer for nearly 20 years, working with Python, PHP, JavaScript, ObjC, Swift, Java, bash scripting, SQL, Terraform, and a bunch of others. Written code for data transformations, web servers, client side JS apps, native mobile apps, and games.Android has been my favourite platform to work with and has offered the best developer experience I’ve found. It’s not particularly close. The SDK has improved significantly over the years, the IDE is wonderful, the feedback loops are short, Kotlin hits the sweet spot between functional and OO code, and Compose is a joy. Although yes, Gradle is a sore spot.IMO the reason why Google have gone all-in on Android Studio is because it’s really, really good. Compare it to Xcode. If you’ve never used a JetBrains IDE, it can feel a little unfamiliar, but I’ve never felt as productive in any other programming environment.

评论 #40743800 未加载

kkfx11 个月前

Because desktops, even modern commercial one, are still kind-of open platform, mobile are their OEM game, devs are uncomfortable guests there.If you are a very large firm you have to accept the OEM bureaucratic terms, if you are a small one you are a bad guest because people must only consume and being fully dependent on the vendor, if programming is ease too many will try and sooner or later FLOSS start to spread and sooner or later people will decide it's time to ditch costly subscriptions to do things alone, knowing it's perfectly possible...The entire modern IT development head in this direction, trying to subtract all power to all users, no matter if "end users" or "intermediate programmers".

frou_dh11 个月前

It's probably like that because there is so much internal Google churn and product development year after year, and a thousand cooks in the kitchen.Old-school stuff like WinForms just seemed like a calmer scene with not so much going on.

mindcrash11 个月前

Instead of using the barebones Android SDK you might want to experiment around a bit with Kotlin.<a href="https://kotlinlang.org/" rel="nofollow">https://kotlinlang.org/</a>Note that Google is using Kotlin internally themselves for writing Android apps because reasons.If you want to have a great multiplatform development experience based on Kotlin, add Kotlin Multiplatform (<a href="https://www.jetbrains.com/kotlin-multiplatform/" rel="nofollow">https://www.jetbrains.com/kotlin-multiplatform/</a>) and you are all set.

clumsysmurf11 个月前

I think its a combination of:* Android having made lots of compromises to get Java running on resource constrained devices, leading to things like manually saving state in Bundles, Parcelables, SavedStataHandle, etc in combination with Component Lifecycles. These deep seated things remain.* Lots and lots of undocumented behavior, poor documentation, etc. The Javadoc is in disrepair for many APIs, being just skeleton but not mentioning semantics, arguments, return values in all scenarios etc.* Lots of API churn, stuff being deprecated constantly. You may need lots of compatibility paths.* Just straight out bad ideas like Content Providers, which are still used in various APIs like DownloadManager (getting status, etc).* Still have plenty of fragmentation and behavior differences (Samsung devices, etc)* Google Policies continue to become more onerous. Seems like more of my effort goes towards administration than actually building. I suspect this is intentional, so only larger teams can get their stuff in Play Store.* Mobile development in general is still kinda like shipping software on CDs, there is some delay for approvals, and some people won't get your update for a bug fix etc

a1o11 个月前

I don't know the why and I mostly code for it in C++ with a thin layer of Kotlin (used to be Java) around it because some things are easier to do there in the API. I guess if I started today I would have a hard time picking up but since it's been 8 years now the knowledge has compounded and I don't know exactly how to tell you. I think it's in the same sense that I have hard time to explain Magic The Gathering for someone when I have been playing it (with a few stops and comebacks) since 1995, it's so many cards, mechanics and history that I don't know exactly how to start someone and keep them interested.I would suggest trying to do something small like a pomodoro app and then think on things you want for yourself - some people have fun with home automation, some people want the perfect note taking app, find something you want for yourself and try to go slow through the docs and tutorials to implement it. Android Studio is pretty great once you get the hang of it.

aristofun11 个月前

Only 2 equally contributing reasons:1. UI is inherently a very complex problem, because of the state. Most of the so called web apps are thin clients with most of the state machine delegated and spread over backend services.2. Android platform was shitty designed to begin with. Terrible architecture, ugly UX, frustrating docs etc.

评论 #40744144 未加载

xt0011 个月前

Gradle is a very strange build system.. it actively downloads things if you are missing things, but then still will only work if you have the right combination of things on your system (on linux at least), and fails in cryptic ways. Not sure I know anybody actively likes Gradle and that entire build system -- there was something previously like ant something, etc.. if you have an older project good luck having it actually build even when trying to use Android Studio.. it seems to only work if you actively use Android Studio quite often and slowly adapt to each random change to keep your project working properly.

gwbas1c11 个月前

Take a look at <a href="https://dotnet.microsoft.com/en-us/apps/mobile" rel="nofollow">https://dotnet.microsoft.com/en-us/apps/mobile</a>. It will allow you to write Android apps in C# in Visual Studio.

评论 #40744022 未加载

dfabulich11 个月前

Android seems about the same to me as desktop Windows/Mac development in all of those regards.* Married to the vendor's IDE: You technically can build without Android Studio, Visual Studio, or Xcode, and it's educational to learn how to build apps without the IDE, so you can debug tricky compilation issues, but for day-to-day development, you've pretty much just got to use the vendor's IDE. `gcc hello.c` will not get you a running Windows Forms app, a running AppKit app, or a running Android APK. (`javac Hello.java` won't even get you an `.exe` file!)* Complex proprietary tool chains: The vendors' build tool chains do a lot of tricky work, including link-time optimization, obfuscation/minification, and app signing/notarization. You technically can ship an app without LTO and without a signature/notarization, but good luck getting ordinary users to install it.* Crufty legacy APIs: Windows and Android have a lot of those. Mac has marginally fewer of them, but that's because Apple is more willing to break backwards compatibility, which is its own kind of hassle. It requires a lot of domain expertise not to accidentally use a bad legacy API on desktop, and Android.* Spotty documentation: All the vendors have spotty documentation. Some parts have excellent documentation, some parts are nearly undocumented, and some parts have outdated/misleading documentation. All of the platforms are popular enough that third parties have written a lot of great blog posts, videos, books, classes, etc. (As a professional software developer, your company should offer an education budget so you can pay for good educational materials.)

ilrwbwrkhv11 个月前

I wonder if this is also one of the reasons why Android apps are usually worse than their ios counterparts.

评论 #40743672 未加载

评论 #40743713 未加载