-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correct the usage of flowOn #1508
Correct the usage of flowOn #1508
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! Alternatively, I think the function we were looking for was collectOn
which operates on the downstream. Perhaps we could replace it with that?
either way:
- Does using
flowOn
on the merged flow allow for parallelism? - Did you check for any other usages of
flowOn
in the app, or is this home screen only? - Did you put a log or breakpoint in the offending function(s) to check they're not on main? I guess we could even call one of those
assertNotMainThread()
kinda methods if we really wanted. or evenif (BuildConfig.DEBUG) assertNotMain()
orassertNotMainIfDebug()
if we use it frequently and want a shorthand.
@@ -60,12 +58,10 @@ class HomeViewModel @Inject constructor( | |||
observeTypingStatus(), | |||
messageRequests(), | |||
::Data | |||
) | |||
.stateIn(viewModelScope, SharingStarted.Eagerly, null) | |||
).stateIn(viewModelScope, SharingStarted.Eagerly, null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
I was looking for something like |
Nice, does it run concurrently with one flowOn after a merge/combine? or should we add appropriate scheduling to each flow? |
Yes they do, just confirmed in the debugger that they run concurrently in different threads as expected. |
Description
flowOn
applies to operators BEFORE not after.