I appreciate that 😁

Thank u so much and good luck !

Congrats man, I ended up finding his channel by searching for "The ultimate MVI guideline"

I will see if i can make a video where we build MVI from scratch. Answering your question on having multiple states for a single ui, im not sure if you can do it with Orbit MVI. But i don't see any advantages of having 2 states for a single screen. You can just add all your screen states in a data class and let your UI observe those states.

Return flow or a direct result, it doesn't matter in my opinion as long as the use cases are testable. And btw i have made another video about the most common Architecture in android development now adays. check it out ukposts.info/have/v-deo/jJ-khIlsbK-Qqo0.html

- There is no better architecture but there is a preference, but there are some considerations before choosing the app architecture like if you have many states the screen, it makes sense to use MVI because it has a better state management and cleans the viewModel. - As was mentioned in the video in context of android, MVI is build on top of MVVM and it's like an expansion of MVVM. In MVP you have a presenter which does the business work and hold your view to notify you about changes.

I wanted to explain the detailed and universal MVI architecture with all of it's components and i looked for a library like obrbit MVI which has the same components that explained in the block diagram. well, the goal of MVI is to clean up the viewModel from too many states and ensure better state management. and i know that we could achieve MVI without using an external library but again, i wanted to implement the global MVI architecture with all its components. Maybe MVI is overkill for independent projects so thats why most android developers preferer to mix between MVVM and the idea of MVI where we create a STATE and pass a data class that has the ui states and take actions from the UI events (intents) then the viewmodel determines what kind of event received and take an action based on that event.

It's because if you will be handling much more complex projects, you need to start in a very good architecture, because refactoring and rewriting codes is too much for a team. From our experience, but if you're sure that your not going to maintain that, go simple. No problem

Thank you But a video like this one is not meant for complete beginners, at least i expect the viewers to know MVVM