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
Currently, LifecycleScopeProvider is a first class citizen in autodispose's API. I'd like to propose making it just an implementation of ScopeProvider, with preferably default handling to match the existing behavior. The goal is to simplify AutoDispose's API by reducing the surface area from 3 to 2 and allow use of LifecycleScopeProvider everywhere ScopeProvider is used.
This would be a major ish breaking change of the library, so we should decide this before 1.0
By default, we could keep it java 7 compatible and have a java 8 artifact that extends via DefaultLifecycleScopeProvider with the default implementation. Alternatively, if we rewrite in kotlin, we could allow it to handle it.
We could actually do this in a non-breaking way until 1.0 by making the new artifact be a different package name (which we'd likely do anyway). Only difference is we'd want to make any implementers use the new artifacts relatively soon, probably in the same release.
We plan to move forward with this. From a high level, there will be two new artifacts: one for the LifecycleScopeProvider, and another for the default implementation that targets java 8/desugar-friendly consumers.
The new artifact will be called autodispose-lifecycle, have a LifecycleScopes utility class with the lifecycle-specific utilities from ScopeUtil, LifecycleScopeProvider, and TestLifecycleScopeProvider.
Currently, LifecycleScopeProvider is a first class citizen in autodispose's API. I'd like to propose making it just an implementation of ScopeProvider, with preferably default handling to match the existing behavior. The goal is to simplify AutoDispose's API by reducing the surface area from 3 to 2 and allow use of LifecycleScopeProvider everywhere ScopeProvider is used.
This would be a major ish breaking change of the library, so we should decide this before 1.0
By default, we could keep it java 7 compatible and have a java 8 artifact that extends via
DefaultLifecycleScopeProvider
with thedefault
implementation. Alternatively, if we rewrite in kotlin, we could allow it to handle it.Open questions for discussion:
@JvmDefault
?The text was updated successfully, but these errors were encountered: