DO NOT MERGE - live data & coroutines experiments #770
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📢 Type of change
📜 Description
This PR has two parts, just sending to share some ideas.
First part is about using the liveData builder instead of launching in scopes and calling setValue on a LiveData instance.
This allows tests to just use LiveData.asFlow() instead of LiveDataTestUtils. Also much nicer organization on how the value is computed (since there is only 1 place to look)
For the test case we want 2 events, unfortunately events get conflated with LiveData.asFlow and test coroutine dispatcher executes all runnables immediately (instead of first come first serve) but adding a yield between two emits in the ViewModel solves it (not great).
The second part is replacing Event class with a regular kotlin channel.
Channels have a fan-out functionality which is explicit (unlike in SingleLiveEvent which had implicit behavior that does not match LiveData). I find it much cleaner and has room to be generalized.
I don't think it makes sense to merge this PR (hence DO NOT MERGE), but i think there is room to move more code into coroutines / flows also cleanup this PRs code.
I think even the LiveData computations can be reduced into Flows all the way until UI (viewModel's public fields that is).
💡 Motivation and Context
Avoiding LiveDataTestUtil.
💚 How did you test it?
ShotViewModelTest
📝 Checklist
./gradlew spotlessApply
before submitting the PR🔮 Next steps
just check it
📸 Screenshots / GIFs