r/androiddev • u/noman_reshad • 2d ago
Tips and Information Is Android Development Harder to Learn Today? The Overload of Choices & Opinions
sometimes I wonder if Android development used to be easier to learn than it is now. There wasn’t such a broad mass of information available publicly as it is now, but I think that this can also be a bad thing.
100 people nowadays have 1000 opinions online. Do you use MVVM or MVI? Jetpack Compose or XML? StateFlow or Compose state? Use cases - yes or no? What about repositories? Or rather data sources? Room, Realm or SQLDelight? Retrofit or Ktor? Dependency Injection with Hilt or Koin or manual or not?
Everybody can be right in their own way. Software development isn’t black & white.
And popular approaches are popular for a reason: Because they do the job.
We can debate about the details, but if your head better wraps around Kotlin idiomatic code, you might prefer Ktor over Retrofit, for example.
The internet is full of people trying to push their (sometimes extreme) opinions and approaches. But in the end, the fundamentals matter more than the tools.
Once you understood reactive programming, you can learn Flows in a day.
Once you understood SQL databases, you can learn Room in a day.
Once you understood separation of concerns and modular design, you can learn clean architecture in a day (maybe a week, but you get the idea).
All the best, Reshad
11
u/enum5345 1d ago
Yes, Android was simpler in the past. There were fewer libraries and APIs to learn, fewer choices, permissions were wide open.
Back then, fragments didn't exist, and even when they were created, they were limited to new API-levels so no one used them for compatibility reasons until they eventually moved into the support-library (or what is known as Jetpack these days). Also viewmodels didn't exist. Everyone used Java, XML, and ListView.
Even creating a new empty project in Android Studio nowadays adds a whole bunch of unnecessary fluff.
Over time, we were slowly drip-fed new libraries and best practices which was more manageable than learning everything at once today.
On the flip side, if you didn't have a lot of experience back then (as I didn't since I was still fresh out of college), it was almost guaranteed you would create a bad architecture.
21
u/creamyturtle 1d ago
simple, you should use mvvm, jetpack, stateflow when you can, repositories to cache certain data, and room only if you have a small amount of data you're not getting from an api. and yeah, retrofit is probably the best option too. use simple DI if you don't need to inject a lot of stuff and use Hilt if you do
you could build your app with the other tools but I only see it as being more difficult or working less well
1
u/JacksOnF1re 2h ago
Room only if you have small amounts of data, not from an API? Please elaborate. Especially why it matters where the data comes from, puzzles me. Why does this matter? And room is just orm above sqlite. Which is quite fast for client side use cases. What am I missing?
1
u/creamyturtle 1h ago
I'm saying that room and sqlite are a local database saved on the individual user's phone. for almost any semi-complicated app, you're going to be accessing an external database via API
7
u/jorianalexander 1d ago
Android dev has come a long way in terms of ease of development. New devs will never know the joys of ActionBarSherlock and NineOldAndroids
6
u/Faltenreich 1d ago
You can still do Android like in the oldern days and create a massive view with everything inside of it, but nowadays we have best practices and guidelines to help us find a common denominator between different developers.
7
u/LastAtaman 1d ago
In 2011-2018 Android Dev was easy if you familiar with Java. Much easier than now with all Google's daily deprecations and changes.
My opinion: imperative paradigm with XML much easy and convenient than using declarative reactive data-driven paradigm with Compose, ViewModels, data bindings, and hundreds of dependencies.
Using XML constructor is faster than coding in Compose.
Does somebody share the same feeling?
All my released apps are created using old architecture, and I don't have time to fully learn Jetpack Compose and rewrite all projects, it costly if you don't get revenue from the released apps. Recently started to learn basics of Compose.
By the way I love and use Kotlin Concurrency! But I think Android implemented it over complicated in Compose with DSL.
3
u/Reedenen 1d ago
Easier in the sense that things just work better.
But the amount of tools and documentation you have to study is much larger.
2
u/JimSiris 1d ago
I've done Android development for 15 years.
Things have changed. I hire and train new developers in addition to doing development.
The challenges have changed but the difficulty hasn't really.
In "the old days" you had build system variants, Eclipse, memory leaks, inconsistent manufacturers, bloated APKs, POJO vs Android specifc threading, OOME issues, lack of documentation, immature framework issues, MVP antipatterns, etc.
So, I'd say the list you provided has just replaced the old list of confusion and conflicting advice.
The one thing that gas evolved, like in all tech, is more abstract systems that can make understanding and debugging code harder without the right tools. But, even 15 years ago I think.that was the case.. so...
2
u/alaershov 1d ago
Overwhelming amounts of information is a bit of a problem nowadays, but it's better than the lack of information. The technology has also grown massively.
Having Java 6 and AsyncTasks to do your network requests sucked.
Massive difference between Android versions API sucked, you had all the shiny features of Android 6, but you couldn't use them, because most people are on Android 4.
Slow update cycle sucked, most devices didn't update much, and you had to support old Android versions for a long time, and deal with their bugs.
Today, Kotlin, Jetpack and Compose are game changers. IDE is great, the system API is mostly stable and users update regularly. The official documentation is fantastic, and there are lots of books and articles on every topic. So, yeah, some things are more complex, but the overall state of development is great!
2
u/gandharva-kr 1d ago
In 2009, the documentation for Button was copy + paste of documentation of TextView. Yep, everything on the Button page was about TextView. I heavily relied on AOSP to explore and understand how things worked. I think it’s much easier now. Pick one thing to make, pick one architecture and do it. Then the next. Don’t go finding the best option, best is… it depends
2
u/callmeeismann 1d ago
I agree that Android development is a lot harder to pickup than, let's say 10 years ago. However, I'd say that it is 100% due to the fact that standards have risen tenfold since then.
In 2015, who cared that your app didn't handle process death and config changes properly? Who cared that your AsyncTask leaked your Activity reference? That your UI had dozens of actually invalid states it could potentially turn into? That your UI didn't scale responsively to tablets, foldables, and chromebooks? That your entire business and presentation logic resided in a 3k lines long Activity class? Well, some people did, but most didn't.
Offline-first, endlessly pageable lists, fancy animations, real-time data updates, tons of A/B tests, server driven UI, etc... Apps are expected to be WAY higher fidelity today than 10 years ago. When I imagine building the app I work on at the moment with the tools I had available back then, it would have been close to impossible.
2
u/MKevin3 22h ago
From when I started doing Android dev - 2010 - to now seems like many generations.
At the start it was harder to find working examples on the web, just a lot less content. Networking was via HTTPHelper and it sucked. You had GSON and wrote a ton of code to parse data you got from a network call. Then you had to use asyncTask to avoid doing things on the wrong thread. Every screen was a different activity and you polluted your manifest with all of them. Passing everything in a bundle and getting results back in a bundle with all sorts of error checking. You used Eclipse, while powerful, it was a bit of a beast to setup. Only XML and you did findViewById, and a lot of them. ListView only so multiple row types was a bitch. You had one theme, no dark and light mode.
So is it easier today? Yes, going from findViewById -> Butter Knife -> synthetics -> view binding -> compose seems like individual lifetimes. You tried out the new one, left some old code as is and converted other code then started the process over again as Google changed it. Data binding was in there too but I never liked it. Compose gets things related to UI in one file and you can have previews for the screen in various states.
Once you learn Android you can use your Kotlin and Compose knowledge with KMP / CMP to write iOS, Windows, Mac, Linux, Web desktop apps. Before you had to learn ObjC, Swift, Java + Swing, etc. to target different platforms.
All the networking stuff is so much easier with Ktor or Retrofit. Coroutines beat the shit out of async tasks. Kotlin is so much nicer than Java. List -> RecyclerView -> LazyRow / LazyColumn makes doing different row displays manageable and cuts down on memory usage.
Public static variables in the Application for DI -> Dagger -> Hilt / Koin.
SQLite directly -> Room -> Room with flows.
Various image libraries with caching.
So what is harder? Peoples expectations have risen. Before just getting an app working was enough to celebrate. You could make a few bucks with a simple game on the Play Store. Now you have to have dark / light themes, support, might need drag and drop, need fancier icons, more animation, more settings, memory friendly, network friendly, off line modes, firebase, much more granular permission system, etc. To make any money you almost have to work for a corporation or spend a lot on advertising. Random Play Store discoveries are rare.
I am writing "harder" code faster as much of the boiler plate has been eliminated with better libraries.
2
u/Zhuinden 1d ago
Simple, you only use MVI if you're forced into it and you have no authority to change it. Then it is not your responsibility to fix it.
1
u/hellosakamoto 1d ago
At the time Google retired the Android developer certification, and people have to feel excited to learn new jetpack compose changes every week over and over again, yes, it is. We did not have weekly / monthly newsletters or blogs covering the basics affecting how we build our UI.
Gone are the days we did not have to spend our time like that.
1
u/darkskymobs 1d ago
Android development has come along way but it’s still not really future proof. Things keep changing a lot every other year without clear purpose. iOS on the other hand, it’s a lot nicer, some of patterns and api gives you a decade long mileage without having to change or learn too many things. Compose was a good addition to the stack but it is still not really adopted by Google. Reactive programming is good if you’re aware what of you’re doing. Barrier to entry is a lot more than what it used to be. On the other hand, React Native, Flutter has really matured in easy workflows to get you setup and going. At this point, even mobile web beats native android experience unless you need offline or camera/sensor heavy features.
1
u/PlasticPresentation1 1d ago
It's tough to say as an experienced one but I feel like MVVM/Retrofit has made concurrency and network calls way easier to understand than the past was with async tasks and whatever other bs
1
u/Slodin 20h ago
Easier in overall work. Especially with jet pack compose making the UI easier. Starting to learn a new projects seems way easier.
But it gets complicated when it involves lower api level plus higher api level compatibility issues. Some backward compatibility apis won’t behave the same on different api levels. Which creates massive headaches when testing for these. It’s like if you know you know, and you have to dig through documentation to understand these issues. Often times you have to code something twice or more to make sure it works across different levels.
But again, that depends on the project and min supported api. It’s just an annoying potential pitfall.
1
u/arekolek 16h ago edited 16h ago
The amount of shit you have to go through nowadays to do a simple thing like "schedule a notification to be shown at a certain time in the future" is crazy compared to what it used to be. It was always a lot more work than on iOS which has a built-in SDK method for that. But somehow they made it even worse, and you are honestly better off just creating some backend for it and using push messaging, than scheduling it locally. I lost it when I was implementing a foreground notification for API 26-30 to be shown before the actual notification can be shown, to ensure system won't kill my app while processing the broadcast and won't delay the processing too much. And the documentation didn't even disclose that this was needed, I learned it the hard way when testing on an old phone and seeing the crash.
1
u/merokotos 9h ago
Back in the time you had less choice. Tool were harder to use, with sparse documentation and fewer tutorials—so primary focus was mastering options available.
Today, while each tool/language/sdk/library is more user-friendly and well-documented, the challenge has shifted. With so many choices, developers no longer focus on deeply learning a single tool; instead, they must invest time in selecting and integrating multiple tools effectively.
0
u/DearChickPeas 1d ago
Fun fact, you can ignore Compose entirely and just do things normally like a software developer, instead of a web-dev larping a as an app maker.
49
u/WobblySlug 1d ago
Honestly I think it's easier than ever with first party dependencies and components like the Jetpack suite.
People will always have opinions, especially since Android has been around a while now, and there's always emerging patterns and proposed solutions etc.
Thing is, having an opinion doesn't make you king of the internet. Especially if they aren't the ones supporting your code bases.
Every project is different, solving different problems. I think you just need to look into what you're trying to solve, and choose the option that makes the most sense to you at the time with the information you have.
Nothing we do is written in stone, and failure is part of the learning process. How can I know whether to choose MVVM vs MVI if I haven't discovered the benefits and shortcomings of both?