Any highlight about app architecture with Jetpack ...

# compose

[gpaligot]

Any highlight about app architecture with Jetpack Compose? We’ll stay with MVVM+LiveData or something new like Flutter and their “block” architecture?

[kioba]

there was a great talk from @Luca Nicoletti about compose and MVI

[Luca Nicoletti]

I’ve been trying it out with MVI, works really well imho 🙂

[gpaligot]

Do you have a link for me?

[Luca Nicoletti]

The video of the talk has not been uploaded yet, I can send you the slides

[gpaligot]

I found your medium article (https://medium.com/swlh/android-mvi-with-jetpack-compose-b0890f5156ac) but I’m interested in your slides too!

[Luca Nicoletti]

The article is a little bit out-dated, was using ViewModel class not in a proper MVI architecture

[Luca Nicoletti]

https://speakerdeck.com/lnicolet/mvi-with-jetpack-compose here’re the slides 🙂

[gpaligot]

Thanks a lot @Luca Nicoletti!

[Paul Woitaschek]

@Luca Nicoletti So what was the library you were using for mvi? There is only a censored quote, dind't make sense to me from reading it only

[Luca Nicoletti]

It’s an internal library we’re open sourcing soon. I also tried using this as a template (https://github.com/bufferapp/android-clean-architecture-mvi-boilerplate) and it’s almost the same

[Luca Nicoletti]

you always end up having a render function which you could trick

[themishkun]

Why even bother with separate library for MVI? It is like one class worth 100 lines of code

[Luca Nicoletti]

That’s another story 🙂 The point of my talk/slides is how we could use Jetpack Compose easily with that architecture, how you implement that architecture is up to you

[alexsullivan114]

Is MVI different from redux if you only have one screen?

[spierce7]

I hate redux. How that architecture got so popular is beyond me. Yes, MVI is very different from redux, and imo is a much better developer experience.

[alexsullivan114]

What's the primary difference? Aren't you still sending actions (or intents) to a class that then reduces them against the current state and pumps out a new state?

[alexsullivan114]

Maybe I just have no idea what MVI really is 😛

[spierce7]

I view MVI as a subset of MVP, that imposes a restriction of a unidirectional flow of data, making it reactive. That’s it’s primary benefit over MVP.

Redux also has a unidirectional flow of data, however it encapsulates the ownership of ALL state into reducers (pure functions that take the input state, and the event, and output the new state, and have no side-effects) that live at the bottom most layer of your application. When I say all state, I mean ALL state. The only way you can modify that data is by submitting events to the reducers, and observing changes in the data.

The reason why I hate redux is how complicated and burdensome it makes simple things, especially asynchronous things. If you have a network call, you probably have to have at least 3 different representations of state for that individual network call (success, error, loading), which means you need 3 different events to modify the state into each of those 3 different states. If you do 2 network requests, on different screens, you’d need 6 different states, and 6 different events. It’s just a lot, and it’s really heavy.

In fairness, by abiding by these rules, you get the ability to rewind and fast-forward events, and state snapshots which is pretty neat, but it’s also not really worth the development cost imo.

[kioba]

I feel like those problems just language limitations not actual problems with redux or MVI. but I see that is a lot of extra code you have to create and keep track of.

[alexsullivan114]

Whereas with MVI internal asynchronous events don't need to come through as intents - is that the idea?