![]() ![]() The workaround solution to this is having the view perform some diffing of states prior to rendering (such as using DiffUtil for lists). Since the output of MVI is a complete view state, there may be situations where the state has minimally changed and the view is tasked to re-render the whole state anyway.There are usually more objects created, and this could put a strain on the GC, but is unlikely to impact performance on modern hardware.You could definitely accomplish the same thing with MVVM since MVI could just be a more rigid extension of MVVM.MVI shines in its more explicit modeling of the underlying presentation logic by forcing it to be represented by a single stream with transformations.The difference is whether the view state stream is exposed (MVVM, common) or whether the view state is applied to the view directly via interfaces (MVP, uncommon). Technically, MVI could be implemented on top of MVVM or MVP. The advantages of this are that you get a single-source-of-truth (SSOT) for the view state, and since the mapping from all intents to all possible views are contained within a single stream reducer it becomes trivial to test the presentation logic. Internally this is represented with a single reactive stream (RxJava, Flow, LiveData, etc.), and the presentation logic is contained within the reducer part of the VM. ![]() MVI is basically a state machine of intents (interactions) -> view states. I'll start by saying MVVM and MVI are both solid approaches for modern Android development. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |