Our very own <@U9D52BJF2> did a review of competing MVI libraries and has come up with some interest...

# orbit-mvi

[Mikolaj Leszczynski]

Our very own @appmattus did a review of competing MVI libraries and has come up with some interesting conclusions. Well worth a read!

https://proandroiddev.com/top-android-mvi-libraries-in-2021-de1afe890f27

[Oleksii Malovanyi]

to see if what Orbit does still makes sense

guys, really? 😆

[Mikolaj Leszczynski]

due diligence we ignored for too long @Oleksii Malovanyi 🙂

[Mikolaj Leszczynski]

great to see we have something unique to offer and that we’re on the right path 🙂

[Oleksii Malovanyi]

keep it going 👍

[miqbaldc]

the library runs actions in sequence. So, while we may expect action2 to complete first, it only starts execution once action1, scheduled first, finishes

The above statement was solved by Orbit-MVI due to its support us doing a parallel decomposition cmiiw?

[Mikolaj Leszczynski]

No, it’s because Orbit launches a coroutine for each intent

[Mikolaj Leszczynski]

but you still have to make sure you’re not doing blocking work on Orbit’s container thread, or it will have the same problem as Uniflow.

[Mikolaj Leszczynski]

When it comes to suspending work though - the unit test in the article suggests that Uniflow does not seem to run separate coroutines for each intent, meaning that suspending work will block until completed - Orbit does not have that issue.