Handling view states using LiveData is pretty easy and can be used both for MVVM and MVI, but the problem begins when we want to show a simple Snackbar like before. At the end, the new ViewState is emitted and UI is updated. View communicates with the ViewModel by triggering events which are then handled inside the ViewModel’s logic, UseCases, etc. In Clean Architecture terms, LiveData is OK to be used in Presentation Layer, but it is unsuitable for other layers, like Domain for example, which should be platform-independent (only Java/Kotlin module), Network Layer, Data Layer, etc.Īs you can see, the picture above shows the desired Data Flow that should be used in MVI. It is closely bound to the UI, so there is no natural way to offload some work to worker threads. It is has to be handled in Android classes and with their lifecycle. So what is exactly the problem with LiveData and LiveEvents?Īs you know, LiveData is a part of Jetpack and it is an Android library. The same solution can be used to display a toast, dialog, navigate to other Fragment, etc.
For example, how can the ViewModel tell Fragmentto show a Snackbar?īy using the LiveEvent (or SingleLiveEvent), a modified LiveData to handle single events, which means it emits the data just once, not after configuration changes again. You create a LiveData object in a ViewModel class to hold some ViewStateand observe it in the Fragment to update UI when ViewState changes. LiveData is a data holder class that can be observed within a given lifecycle. Most of you should already know LiveData and how it works. Another words it is a Retrofit service implementation or some wrapper class around it.Last year routines library introduced two new Flow types, SharedFlow and StateFlow, which also have their mutable types - MutableSharedFlow and MutableStateFlow.Īndroid community started wondering… Which one should I use now? LiveData or the new types? Is LiveData deprecated now? I also need to propagate back to "smth" all user inputs to the "name" fields. With this concept I need a single source of data. I'll call Model from the MVI concept State just to distinguish with the Model from MVVM. I want to implement this screen via MVVM architecture, combined with the MVI concept. When user presses this button all Items with their ids and optianally (if user has input any) names are sent to backend. Thus each cell displays id and additionally it displays an input field, which allows user to input name.
Each item in the ListView is represented by LsitViewItem class, which adds optional name property to the id property of the Item.It receives a list of Items from another screen.I'm trying to implement a simple screen, which idea is the following:
0 kommentar(er)
