Hey, I came across this article a while ago, and h...

# android-architecture

[Bart Peereboom]

Hey, I came across this article a while ago, and have since been playing around with it
Has anyone else seen this pass by, and what do you guys think of it?
https://medium.com/@aumaidkh/toad-a-kotlin-first-architecture-pattern-that-finally-made-my-viewmodels-boring-b615a9ab6c30

Here's an example of how I applied it, which pretty much matches the article, but it shows it in a 'real' project
https://github.com/CinqueIzumi/Softcover/tree/main/feature/book_detail/src/main/java/nl/rhaydus/softcover/feature/book_detail/presentation

[Tgo1014]

The action itself set the state of the view? What if two actions trigger at the same time? Won't this be a problem? 🤔

[Bart Peereboom]

So the actionscope.setstate is basically just a disguised stateflow.update, which (as far as i know) should be safe for concurrent executions

One of the things I do think would be an issue is having stale data, f.e calling scope.currentState, then executing code after which you update using scope.setState { state.copy() }

Then again, just saw your message and havent tested it personally, but i believe it should be fine?

[Ryan Payne]

Looks a lot like MVI: https://proandroiddev.com/yes-that-is-mvi-674f810ca4fe

[Bart Peereboom]

It does (and is)!
As a side note, that's a good article!

I'd say that the biggest difference (compared to how i had my codebase set-up beforehand) would be the extracting of the logic to actions & data/flow collectors being separate files

I do like the idea of the expansions just being separate files, clear separation, but at the same time I am a bit conflicted / wondering if it's not just overkill, and whether all the boilerplate / not having a centralized view of the logic anymore is really worth the trade-off

I can see it being quite nice to prevent merge requests / extra manual actions required when multiple developers are working on f.e the same viewmodels, as you'd never be 'in eachother's way', but how common would that really be in the first place

[leodeleon]

Architecture is inherently opinionated; this model streamlines scaling if it aligns with your app's needs.

Even with type safety, ViewModel bloat remains a risk. To manage varying screen complexity, enforce core principles while allowing a minimalist architectural subset for simpler features.