MVC, MVP, MVVM architecture design approach is widely used in Android. In essence I think MVC and MVP decouple the View layer code into Controller/Presenter. As the business gets more complex, the code in C/P accumulates more and then starts to decouple some models or interactors or whatever. As the business becomes more complex, each layer of the business becomes more coded, and then various layers of design are created, etc…
Going back to the simplest MVC and MVP patterns, we can see that both design patterns create a problem.
Both Controller and Presenter need to hold a View. The View is passed in various ways.
Is there a way to solve both decoupling and value passing problems?
Therefore, I tried a new architectural approach in the actual project as follows:
Widget: A page-level Widget, StatelessWidget, or StatefulWidget that displays the UI.
ExtensionWidgetUI: Extension of a Widget. This is the specialized repository for various functions that return widgets.
ExtensionWidgetController: the Controller of the business, it is also a Widget extension. But you can think of it as a Controller that handles business.
ViewModel: HERE I use it with a Provider. It is specially used with Controller to provide UI data support. Each ViewModel mixin a LoadData.
LoadData: In most cases, a page must be loading, loading completed, or loading failed. So a load of page data is maintained for Controller and Widget access.
Such as file related page code: Widget:
ExtensionWidgetUI:
This is the Android EQUIVALENT of XML, providing UI components. Since extension is used, there is no need to pass key, context, etc. It can treat itself as a Widget to generate individual UI widgets.
ExtensionWidgetController:
Controller uses get the page data, and then update the UI using the ViewModel, so there’s not much to say. .
The ViewModel is created in the Widget, so it is easily accessible without passing values.
However, please do not create anything new in the above two extensions, such as variables, etc.
Since extension was born as a Widget, it can’t “be itself.” If you do, the IDE will report the following error.
ViewModel: That’s what you mean by ViewModel, no more.
LoadData: This is the only one that describes the state of the page, if someone likes to put it with the ViewModel and extract a BaseViewModel.
conclusion
This, in my opinion, not only solves the problem that controllers and Presenter need to pass a series of parameters when they are created in MVC and MVP. It also implements page-level modularity, decoupling code for different responsibilities from a StatefulWidget or StatelessWidget page. At the same time, it does not affect the use of state management frameworks such as Provider. The pro test has not found some problems, if found any fatal problems, please leave a message to point out the problem, thank you. After several years of Android development using MVC, MVP, why not try a new game?