3 ms·

What is MVI?

by scns 6y ago

What is MVI?

sdiw 6y ago
Model-View-Intent, I guess.
lubonay 6y ago
MVI stands for Model-View-Intent. It's a state management pattern that uses unidirectional flow. Basically you send events (Intents, similar to Redux actions, not to be confused with the Android Intent class..) to your Model, which does a state update and sends out the updated state to the View.
- scns 6y ago
  Ah okay. Seems to be another name for Model View Update aka The Elm architecture aka Flux pattern.
  - on_and_off 6y ago
    I just skimmed https://guide.elm-lang.org/architecture/buttons.html https://guide.elm-lang.org/architecture/buttons.html . It does sound very familiar ! Yeah there is nothing new there (and MVI on Android having been heavily influenced by what's going on on other platforms is readily acknowledged). It is newish (it has been there for several years now) as far as "trendy" Android architecture patterns go. We started with a bad implementation of MVC for several reasons : - what Google ended with (which does not look like it fits what they initially intended, but I digress) with its god Activities has encouraged the community to go in that direction. - when Android was first released, the smartphones of the time were heavily CPU and memory constrained. The way applications were built was to best fit these constraints (sometimes in naive ways). And again, I am not advocating for all problems to use MVI or that it is the one architecture to rule them all. Just something interesting that was very likely not in gp mind 7 years ago.
on_and_off 6y ago
to add on top of what lubonay wrote, this unidirectional data flow allows to solve a wide range of problem in how we handle state (and its changes). so you have - the state, only containing pure java/kotlin objects) - reducers to handle state changes. Basically a reducer is a method that takes a state as input (and often another parameter, like e.g. an user input) and creates another state as output. - and a model of your ui, that is created from each state. This works very well to have fully testable business logic (which is where the no Android objects is nice, so tests can just run on the JVM) and think about how both state and view changes (both state and view states are immutable, and are altered by copy). Again, not necessarily something I say that grandparent absolutely needs, but if they want to try something new, it is there.

What is MVI?

by scns 6y ago

What is MVI?

sdiw 6y ago

Model-View-Intent, I guess.

lubonay 6y ago

MVI stands for Model-View-Intent. It's a state management pattern that uses unidirectional flow. Basically you send events (Intents, similar to Redux actions, not to be confused with the Android Intent class..) to your Model, which does a state update and sends out the updated state to the View.

scns 6y ago
Ah okay. Seems to be another name for Model View Update aka The Elm architecture aka Flux pattern.
- on_and_off 6y ago
  I just skimmed https://guide.elm-lang.org/architecture/buttons.html https://guide.elm-lang.org/architecture/buttons.html . It does sound very familiar ! Yeah there is nothing new there (and MVI on Android having been heavily influenced by what's going on on other platforms is readily acknowledged). It is newish (it has been there for several years now) as far as "trendy" Android architecture patterns go. We started with a bad implementation of MVC for several reasons : - what Google ended with (which does not look like it fits what they initially intended, but I digress) with its god Activities has encouraged the community to go in that direction. - when Android was first released, the smartphones of the time were heavily CPU and memory constrained. The way applications were built was to best fit these constraints (sometimes in naive ways). And again, I am not advocating for all problems to use MVI or that it is the one architecture to rule them all. Just something interesting that was very likely not in gp mind 7 years ago.

on_and_off 6y ago

to add on top of what lubonay wrote, this unidirectional data flow allows to solve a wide range of problem in how we handle state (and its changes). so you have - the state, only containing pure java/kotlin objects) - reducers to handle state changes. Basically a reducer is a method that takes a state as input (and often another parameter, like e.g. an user input) and creates another state as output. - and a model of your ui, that is created from each state. This works very well to have fully testable business logic (which is where the no Android objects is nice, so tests can just run on the JVM) and think about how both state and view changes (both state and view states are immutable, and are altered by copy). Again, not necessarily something I say that grandparent absolutely needs, but if they want to try something new, it is there.