Let’s clarify some misconceptions around android development these days
Forget the Formalities ! There’s no introduction for this blogpost 😅 (or maybe I have a blank page syndrome). Let’s try debunking some myths around android development and clearing the air ! (oh actually this seems to be a good intro, isn’t it ? 🫣).
Remember, this is my perspective (backed by facts)
Android development is not about Jetpack Compose
While Jetpack Compose is a powerful toolkit for building UIs in Android, Android development encompasses much more than just UI design. To become a proficient Android developer, it’s essential to understand fundamental programming concepts such as Object-Oriented Programming (OOP), be proficient in programming languages you will be using (Kotlin for instance). Additionally, developers must handle networking data using database and APIs, design robust app architectures, manage the android lifecycle, and optimize app for various devices, etc. These skills collectively enable developers to build robust, efficient, and high-quality Android applications.
Dependency injection is not about using Hilt
“In software engineering, dependency injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally” — Wikipedia
The essence of DI is to decouple the creation of dependencies from the classes that use them, making it easier to manage and test components in isolation. This can be achieved manually through constructor injection, method injection, or property injection without relying on any frameworks. Unfortunately, some developers become overly dependent on frameworks like Hilt and struggle to implement DI principles without them.
While Hilt, Dagger, Koin, and other DI frameworks simplify the process by automating the wiring of dependencies (and doing other stuffs for you), understanding the core principles of DI is essential. It will even make you more comfortable with these frameworks, and you will know why you are (or not) using them.
DI is about the pattern itself, not the frameworks used to implement it.
The Jetpack ViewModel is not the “ViewModel” of MVVM
Contrary to popular belief, implementing the Model-View-ViewModel (MVVM) architectural pattern does not necessarily require the use of the Android Architecture Components (AAC) ViewModel (or Jetpack Viewmodel). And a common misconception is that using the Android Jetpack ViewModel automatically means you’re following the MVVM architectural pattern. This is not the case.
The Jetpack ViewModel is a lifecycle-aware component designed to manage UI-related data in a way that survives configuration changes, such as screen rotations (we can even handle that in different ways). While it is a valuable tool, using it alone does not constitute an MVVM architecture.
In the MVVM, the ViewModel acts as an abstraction layer that encapsulates the state and behavior of the View, and exposes properties that the View can bind to. It also acts as a value converter, primarily responsible for preparing and exposing data objects from the Model to the View layer in a format that is easy to manage and present.
Unlike the Presenter in the MVP pattern, which typically holds a reference to the View, the ViewModel in MVVM does not maintain a direct reference to the View. Instead, it relies on data binding or other mechanisms to synchronize data between the View and itself.
All this long paragraph just to tell you that you can use the Jetpack ViewModel in your project and not be implementing MVVM, and conversely, you can follow MVVM principles without necessarily incorporating the Jetpack ViewModel.
You Can Call the Repository Directly from the ViewModel
Many proponents of Clean Architecture (on Linkedin and X) advocate against calling the repository directly from the ViewModel, viewing it as a shortcut or a violation of architectural principles. Introducing unnecessary layers, such as creating UseCase classes that merely act as intermediaries between ViewModels and repositories. This approach often results in over-engineering, where developers end up with projects filled with UseCase classes that serve little purpose beyond calling a repository method and returning data. And the fun fact is they place the logic meant for UseCase in the wrong place (like the ViewModel)
Note that it’s crucial to evaluate whether adding these extra layers genuinely benefits your project. For simpler applications or scenarios where business logic remains straightforward, calling the repository directly from the ViewModel can simplify your codebase and improve clarity.
This trend of advocating for unnecessary layers in architecture is gaining popularity on social media. It can be misleading, especially for developers who are just starting, as it may encourage them to adopt complex architectures without clear benefits.
Google recommendations are just “Google recommendations”
Google’s recommendations and “best practices” should be approached with critical evaluation. It often involve deprecating what they previously recommended and then reintroducing those deprecated practices later on.
You are not a big company
You should approach “industry best practices” with a critical eye, considering how well they align with your project’s specific goals, timelines, and resources. Blindly adopting practices solely based on the endorsement of big tech companies can lead to unnecessary complexity, over-engineering, or inefficiency. Instead, it’s crucial to evaluate each recommendation in the context of your own development environment and adapt them judiciously to ensure they truly benefit your project.
It’s easy to fall into the trap of assuming that what works for large tech giants will work seamlessly for smaller development teams or individual developers. What works best for them might not necessarily be the most efficient or practical solution for smaller projects or teams with different needs and constraints.
Start with a good foundation and scale up as needed.
Conclusion
This article doesn’t cover every myth circulating about Android or software development in general. My goal was to underscore the vital importance of discerning and evaluating the information you consume. It’s crucial to prioritize practicality over blindly adopting popular practices or following tech influencers.
Till next time…
