Expectations when developing an Android Application

[u/Bon_Appetit357]

I started to delve right into Kotlin Programming Language under Android Studio and it's getting interesting. But as I get further and further to the field, I realized that it wasn't really easy when dealing with advanced topics such as State Hoisting, Mutable States, ViewModels, and Hardware Services (Bluetooth, Camera, and Accessibility).

Therefore, as a hobbyist, I would like to ask what are the things I should expect while coding (i.e. getting frustrated or stuck)? Do I also need to code my own Unit Tests and Android Tests to confirm if it works? And finally, what are the best practices or habits that makes the code much more readable?

[u/elnoxvie]

Speaking from experience, i would suggest building a strong understanding of Kotlin fundamentals, including syntax, coroutines, and Flow. You should also understand the Android lifecycle, core components, and recommended development practices.

MVVM and MVI are widely used in modern Android development to separate responsibilities and organise code clearly. Following these pattern consistently gives your app a solid structure and makes it easier to maintain.

Good Naming techniques and SOLID principles can also help you write code that is easier to read, test, extend, and debug.

Modularise your application where appropriate. For example:

• core/network
• core/database
• feature/subject

A modular structure improves separation of concerns, encourages code reuse, and may reduce build times as the project grows.

Follow good Kotlin practices:

• Prefer val unless a variable genuinely needs to change.
• Use Kotlin’s null-safety features.
• Keep functions and classes focused on a single responsibility.
• Avoid unnecessary complexity and duplication.
• etc

Automated tests catch problems early, provide faster feedback than repeated manual testing, and give you confidence when changing existing code. They also help making sure that your application remains reliable before deployment. Testing should be part of your Android arsenal.

If you follow all the good practices mentioned in the Android and kotlin Documentation, you will save lots of trouble in the future.

Lastly, you could also make use of AI but don't trust it blindly.. Read every code generated. Make sure you understand what's being generated. Having said that hands on (without relying on AI) is great way for learning.

[u/Bon_Appetit357 → u/elnoxvie]

Thanks! I also tried arranging each Kotlin files by Architectural Type, which is similar to yours. I also kept hearing about the MVVM and MVI model, so maybe I will keep trying on implementing it.

Currently, I am dealing with asynchronous tasks (i.e. Background Timer) and it involves a new kind of data type called Job. In your opinion, if you are familiar with it, is it really that useful?

[u/elnoxvie → u/Bon_Appetit357]

If you're referring to ⁠Job⁠ in Kotlin coroutines, then yes, it's really helpful! Modern Android relies heavily on coroutines for asynchronous tasks.

If you run a long process on the main thread e.g. like fetching 100k rows and sorting them, the UI will freeze, leading to an ANR (Application Not Responding) crash. Coroutines allow us to suspend functions and release the main thread for other to use while background work runs on threads like ⁠Dispatchers.IO⁠ (for fetching) or ⁠Dispatchers.Default⁠ (for heavy sorting). Once the result is ready, the coroutine resumes right where it was paused.

The operation is sequential, clear and clean, preventing something we called callback hell in programming.

[u/best-home-decor]

Expect to get intimately familiar with Logcat output. It will become your best friend and your worst enemy

[u/Bon_Appetit357 → u/best-home-decor]

Oh, I recently discovered this feature last week and it was life-changing! It helps makes the interaction between each UI and the values in each Mutable States much more transparent.

Before discovering it though, it was a pretty hellish journey when it comes to guessing what values are being stored after each interaction.