One of the hardest things you’ll ever have to learn is Android. This framework is so challenging that it borders on nightmarish. I know of a few people who cried Android with anguish in their sleep because its vast, imposing riddle refused to reveal itself to them.
It would chase them in torment, revealing its numerous facets at every corner of their terrible ordeal.
Many keyboards lie in ruin at dumpsides from souls who were endlessly trapped in compile-time/run-time errors.
And unless you’re one of those few anomalies that breathe code as H2O, you’ve probably encountered the same challenges.
I am not here to help your despair because you deserve and need every bit of it. I am here to say that more is coming. However, we can create a structure that can help us cope and subsequently begin improving.
A big part of understanding these structures involves finding your niche in Android. What about Android do you like? What speaks to you?
What are you perceptible to?
Here are the four major components that constitute Android.
The frontend: This includes the UI(User Interface) components that a user engages with. The more you improve the elegance and functionality of the designs, the more the UX(User Experience) improves. These components would then be exported whole or in parts into the XML file of your Android Studio project. Or directly into the backend as composables using Jetpack-compose. Common UI/UX design + Prototyping tools include(not limited to) Figma, Sketch and Adobe XD.
The Xml or composable. Historically, XML components would be declared on their own file, linked to the Kotlin backend folder. They would be located by their assigned ID and manipulated from there. The standard way was to use the ‘findViewById’ call, which meant that Android understood them as views with certain qualities. By the method call above, you are just fetching the qualities of that view for whatever it is you need them for. But finding views by their ID is now considered outdated. Two new practices have overtaken it. A. View-Binding, B. Jetpack compose. Both still declare views by their ID; the only difference is that the class making the call does not have to constantly find them whenever it’s loaded.
The backend. This is where the bulk of the work is done. This is where all the mysterious twists and turns occur that allow your app to function as it does. In some circles[according to some people], the entirety of steps 1 to 3 would constitute the frontend, and in some, the fullstack(frontend and backend). Usually, step three would include step four, but I will separate the two for this presentation. Just know that the vast majority of developers do work on the third step.
The final step is serverside work or stored procedures. This SQL code can be manipulated repeatedly (created, read, updated and deleted). This has two components: 1. The local database, which is entirely held within the Android ecosystem. The best tool for this is the Room database, built on the SQL paradigm and designed to simplify data manipulation. 2. Remote database. As its namesake, this one is stored on a server or multiple servers somewhere and can be manipulated using APIs that come standard with the solution provider you’re using. Or, if you have your own internal server, you would use DBeaver | pgAdmin(PostgresSql), etc., for the data administration. Dbeaver is one of many. It’s one that I am somewhat familiar with.
And there you have it. Pick yours and start there. However, be mindful that all are co-dependent on each other. They’re all bolts in a wheel. But it will serve you well to play with them and see where your interest lies.
Eventually, you will become proficient in all of them, as am I. And Android will start feeling much more rewarding(mainly through positive feedback). Now that I think back, Android is not complicated at all.
But attitude goes a long. And I assure you that yours will stink now and then as you learn about this paradigm and yourself.
But you’re already there. Start with what you’re drawn to, anywhere from steps one to four, then fail forward.
If you feel stuck, write to me; hopefully, I’ll help you debug your issue. Please don’t count on it, though!
Go back here.