preface
Nice to meet you!
Last week, I published an article about Jetpack MVVM in various technology communities. I thought that there would be no one to pay attention to this article. However, as soon as the article was published, everyone from architects and technical managers of well-known domestic companies to Android developers of world-class companies was reading it.
And according to reader feedback, most Android developers have recently stepped out of their comfort zone and started to try to understand and apply Jetpack MVVM to real projects.
Unfortunately for Jetpack MVVM, the Internet is full of piece-together, word-by-word, and codied-through articles, which not only fail to provide a complete perspective to help clarify the context in the first place, but also frustrates and discards those who have not yet started Jetpack.
The good news is that this time around, we’re here with a well-honed list of Best practices for Jetpack MVVM!
| Interactive design that you can’t put down! | It’s a coherent user experience | Unified distribution of the only trusted source |
|---|---|---|
 |
 |
 |
Seamless switching of landscape and portrait layouts
Project introduction
I have three years of experience in mobile terminal architecture practice and design, and have led or participated in more than ten large and medium scale projects reconstructed by the team. I have a deep understanding of the efforts made by Jetpack MVVM architecture in establishing a standardized and standardized development mode to reduce unexpected errors.
In this case, I’ll show you how The Complexity of Jetpack MVVM can easily take a very error-prone development effort that would take half a day to complete with just a few lines of code.
👆 👆 👆 to highlight
In this project,
We set up two distinct layouts for horizontal and vertical, and with the help of life cycle, rebuild mechanism, state management, DataBinding, ViewModel, LiveData, Navigation, and so on, with a few lines of code, It’s easy to seamlessly switch between landscape and portrait layouts without any unexpected errors.
We’ve arranged play status indicators (including the status of the play pause button, the current index of the playlist, etc.) on multiple Fragment pages, and shown you how and why a ViewModel or singleton can be used with LiveData as the only trusted source. To achieve uniform distribution of traceable events across the application scope.
We arranged for cross-page communication between fragments and activities, respectively, To show you how to implement lifecycle secure, event source traceable page communication (event callbacks) through UnPeekLiveData and application level SharedViewModel based on the Demeter principle (also known as the least known principle).
We’ve arranged view controller, ViewModel, and DataRepository in ui.page, data.repository, and bridy.request directories to show you the architecture of one-way dependencies. How to avoid problems such as memory leaks by layering data requests and responses.
The code for this project is written in Java, a standardized industrial language certified by ISO. Also, in most of the classes included in the above directory, we provide rich comments to help you understand why skeleton code is designed the way it is and what unexpected errors can be avoided in the context of software engineering.
In addition to mastering MVVM best practices in complicated code, some of the things you can get from this open source project include:
- Clean code style and standard resource naming convention.
- In-depth understanding of view controller knowledge and correct use.
- Full use of AndroidX and Material Design 2.
- ConstraintLayout Constrains best practices for layouts.
- Excellent user experience and interaction design.
- Never use Dagger, never use fancy tricks, write complicated and obscure code.
- One More Thing:
The One More Thing is:
See GitHub’s jetpack-MBVM-best-Practice repository for more details