You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal allows us to move on from RxJava only implementation.
The general idea is to have a minimalistic "core" as a Kotlin MPP module with our own implementation of the base types: Source<T>, Consumer<T>, Feature and Binder.
The framework level contains a set of extensions to convert between "core" types to framework ones (e.g. from Source<T> to ObservableSource<T> from Rx and vice versa). In current PoC, we need to provide the following implementations:
Conversion between Source and Consumer to framework types
Feature implementation with framework source type (optional)
Binder extensions for framework type (optional)
As we don't do any thread/concurrency management in the "core" implementation, I suspect we need to have some checks (similar to current SameThreadVerifier) in place to prevent race conditions.
The text was updated successfully, but these errors were encountered:
ShikaSD
changed the title
Multiframework/platform support
Multi - framework/platform support
Jun 24, 2019
I love this idea; it would make the adoption of the framework more flexible if it's possible to have adapters for Flow, Reaktive, RxJava2/3. Besides, it would be helpful to decouple the reactive implementation of a feature with the framework itself.
I wonder if there is any progress in this direction and how to contribute to making it real.
The PoC link is broken/not visible
This proposal allows us to move on from RxJava only implementation.
The general idea is to have a minimalistic "core" as a Kotlin MPP module with our own implementation of the base types:
Source<T>
,Consumer<T>
,Feature
andBinder
.The framework level contains a set of extensions to convert between "core" types to framework ones (e.g. from
Source<T>
toObservableSource<T>
from Rx and vice versa). In current PoC, we need to provide the following implementations:Source
andConsumer
to framework typesAs we don't do any thread/concurrency management in the "core" implementation, I suspect we need to have some checks (similar to current
SameThreadVerifier
) in place to prevent race conditions.The text was updated successfully, but these errors were encountered: