FOR DISCUSSION: Using coroutines for login #5695
Draft
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.
I split the
NetworkingModule
into 3 parts with the idea that as classes migrate to use coroutines they will move from one module to the other.NetworkingModule
with common stuff that wont be changing (gson, cookie store, client classes, etc)RxJavaApiModule
for API interfaces that still use RxJavaApiModule
for API interfaces that run using coroutinesSince suspend functions need to be called from a coroutine (or another suspend function) and I cant just convert the
LoginActivity
from Java to Kotlin, I introduced a view model. TheLoginViewModel
gives us a neat viewmodelScope to run suspend functions from, and is easily created and called from Java code. (Google's view models will also survive config change too, so we should definitely look at adopting them to deal with the myriad of other related bugs)All of that is the support ready for the real change of moving to coroutines. Check out the
LoginClient
andLoginInterface
for making API calls.