Status Update
Comments
ha...@gmail.com <ha...@gmail.com> #2
This is a good idea and definitely worth investigating.
I think there's something to be said about what scope these coroutines would run in, but it should be possible to pass it back from adapter internally.
ha...@gmail.com <ha...@gmail.com> #3
Thanks for the suggestion!
uc...@google.com <uc...@google.com> #4
I was thinking of something more upstream. I may be wrong, because I'm just getting started with this new library
Using the scope of the adapter in case of a configuration change would cancel the coroutine, and the cachedIn operator wouldn't cache the mapped value, and some operations would have to be done multiple times.
Maybe using the scope on the producing side of the PageEvents, like in PageFetcher, could be an option.
Using the scope of the adapter in case of a configuration change would cancel the coroutine, and the cachedIn operator wouldn't cache the mapped value, and some operations would have to be done multiple times.
Maybe using the scope on the producing side of the PageEvents, like in PageFetcher, could be an option.
Description
- com.android.tools.build:gradle:3.2.0-alpha17
- androidx:1.0.0-alpha3
- com.squareup.retrofit2:converter-gson:2.4.0
- com.squareup.retrofit2:retrofit:2.4.0
I was trying to refactor my Kotlin project to use Androidx components but I kept getting this compilation error with the package retrofit2 (and any classes under it) not being found. When I set android.enableJetifier to false in gradle.properties, I don't get the compilation error anymore.
One thing to note is if the class importing Retrofit is written in Java, Jetifier can compile the project with no issues even if android.enableJetifier is set to true. I've attached a minimal reproduction of this bug with the Kotlin and Java-equivalent classes.