I recommend <https://twitter.com/VasiliyZukanov/st...

# android-architecture

[Brendan Weinstein]

I recommend https://twitter.com/VasiliyZukanov/status/1206211507551375360?s=19 for some useful framing on design pattern trade-offs.

One concept I like from CoRedux (https://github.com/freeletics/CoRedux) is you can use the design to enforce a log of all state changes. This is useful for sending breadcrumbs on crash reports. I have been playing around with implementing a similar pattern using coroutine flows.

If we expand the discussion to what are some of the best ways to write an application, I am jealous that react/redux devs can replay state and hot reload.

[rkeazor]

That thread was a whole lot of ranting just to prove that MVP scales lol... Redux is a good pattern, but I feel its not synthetic to android's current framework. These type of patterns would shine more in a Declarative Framework(Flutter,React or ReactNative,swiftUi, jetpack Compose).... But in our current framework you would end up creating alot of boilerplate to encapsulate state. There is no hot reload in android as of yet, the closets thing we got to that is instant run lol... And we will almost never replay state, it just doesn't correlate with our current framework

[rkeazor]

I feel the same about MVI. like creating reactive stores and making things as functional as possible is cool and all. But you will end spending a great amount of time just setting up general scaffolding for each feature to fit the architecture

[Brendan Weinstein]

I think the tweet author was expressing frustration with folks treating discussions around MVP/MVI/MVC like fashion, dismissing or promoting one pattern based on what is a sense for the community pick. I think a few responses in this channel might jive with that.

The author is at Slack and they probably have a large team. My guess is most of their code is structured so you have FeatureView, FeaturePresenter, and WidgetRepository, and that some folks are pushing to use some MVI variant. I can imagine his stance being that if you designed your app such that presenters survive configuration changes, and your goal is to move towards something MVI-ish you can implement a unidirectional flow of data within your presenter by just changing the contract to something akin to what we see in ViewModel's, the only difference would then be the class name. And you can similarly outsource work to repositories and datafetchers so your number of lines of code (LOC) don't become unwieldy.

Agreed there is a lot of wiring/scaffolding necessary for setting up a redux-like pattern. I started off by copying the pattern in https://github.com/kaushikgopal/movies-usf-android and nearly abandoned that approach a few times out of frustration for how much wiring it required. I am glad I gave it a try. I used to work on Keepsafe, an app for encrypted document store. For a few of the trickier bugs around syncing I went through some time-consuming cycles of instrumenting breadcrumbs, releasing the app, realizing I wanted to track more state and adding in more breadcrumbs. Now I am more open to approaches that require upfront wiring but carry some benefits for more quickly understanding how a specific state is tied to a bug and possibly making it easier to write a test for generating that state.

Reading through some questions here and elsewhere about how to handle scrolling or implementing a text editor with MVVM/MVI has me questioning if maintaining duplicate state is always a good idea. I haven't dug into jetpack compose yet either.

I abandoned instant run after a few bad experiences. Seems like a lot of folks did. Maybe it can make a turnaround.