rih-carv / livecallback Goto Github PK

Provide a simple sample application showcasing main features, behaviors and use cases

Describe the bug
The library throws an exception while trying to register a recursive callback inside of its own body. I don't know if anyone would ever try to do something like this, but it would be nice to be resilient supporting this possibility of use.

To Reproduce
Steps to reproduce the behavior:

1. Register a callback that tries to register itself again inside of its own body when invoked (achievable by creating the callback instances from a function, probably also from a computed property)
2. Invoke the callback
3. Then a ConcurrentModificationException is thrown

Expected behavior
The inner callback should be successfully registered for future invocations.

Context details (please complete the following information):

• Device kind: Emulator
• Device: Google Pixel 2
• OS: Android 11
• LiveCallback version: 1.0.0

Additional context
Minimal code to reproduce:

val registry = TokenizedSimpleLiveCallbackRegistry()
fun createCallback(): SimpleCallback = {
    registry.register(lifecycle, callback = createCallback())
}

val token = registry.register(lifecycle, callback = createCallback())
registry(token)

Relevant stack trace chunk:

2022-10-12 00:51:13.764 9554-9554/com.ricarvalho.livecallback E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.ricarvalho.livecallback, PID: 9554
    java.util.ConcurrentModificationException
        at java.util.ArrayList$Itr.next(ArrayList.java:860)
        at com.ricarvalho.livecallback.LiveCallbackContainer.invoke(LiveCallbackContainer.kt:72)
        at com.ricarvalho.livecallback.registry.TokenizedLiveCallbackRegistry.invoke-4goFEak(TokenizedLiveCallbackRegistry.kt:105)
        at com.ricarvalho.livecallback.registry.TokenizedInputLiveCallbackRegistry.invoke-4goFEak(TokenizedInputLiveCallbackRegistry.kt:97)

Migrate all the declarations and definitions of dependencies, plugins and their respective versions to a Gradle version catalog (preferably to a conventional libs.versions.toml file): https://docs.gradle.org/current/userguide/platforms.html#sub:central-declaration-of-dependencies

Allow to register and store callbacks tied to Lifecycles lifetimes and states

Is your feature request related to a problem? Please describe.
Today, if an invocation on registry happens while there's none matching callback registered, this invocation is lost forever.

Describe the solution you'd like
It would be nice to have the option to hold/preserve those invocations until there's at least some registered callback to handle them. Also, having a screen that showcases this behavior in the sample app would be great.

Describe alternatives you've considered
There's a draft of a possible structure that makes this request feasible at the feature/postponable branch.

Migrate plugins definitions from build.gradle's (root project) buildscript block to settings.gradle.kts's pluginManagement block:

• repositories
• dependencies (classpath(...))

Integrate Qodana on the analysis.yml workflow: https://github.com/marketplace/actions/qodana-scan
Hint: there's a simplified version of this workflow at the feature/code-analysis-improvements branch that can be a good starting point for this 🙂

Allow to invoke previously registered callbacks, distinguishing between different callback origins (declaration/instantiation locations in the code) in a way agnostic to their instances

Provide public API docs (for use inside IDE and also as a web page)

Is your feature request related to a problem? Please describe.
That would be nice to have extension functions that simplifies usages, as the structures as is may lead to some boilerplate code.

Describe the solution you'd like
There could be some extensions to:

1. make the invocation of multiple callbacks more straightforward
2. simplify the invocation of callbacks where a matching lambda signature is expected (started a draft of this at feature/extensions branch)

• This could be used like so:
  • Legacy SDK code expecting a lambda callback:

    fun doSomething(callback: (param: String) -> Unit) { /* long running operation followed by callback invocation */ }

  • User code transforming a previously registered callback seamlessly through an extension function:

    val token = registry.register(lifecycle) { /* callback code */ }
    sdk.doSomething(token asLambdaOn registry) // or sdk.doSomething(registry lambdaFor token)

  • Instead of the common current approach:

    val token = registry.register(lifecycle) { /* callback code */ }
    sdk.doSomething { registry(token, it) }

3. make callback registration more concise and idiomatic, by automatically getting the Lifecycle/LifecycleOwner from the available scope

• This could be used like so:
  • User code registering a callback inside of an Activity/Fragment omitting the Lifecycle parameter:

    with (registry) {
        token = register { /* callback code */ }
    }
    
    // this could be achievable in the future, when context receivers becomes stable:
    val token = registry.register { /* callback code */ }

A new module/artifact (to an opt-in usage style, like by eg. androidx.lifecycle:lifecycle-extensions) containing those extension definitions (also exposing the main module as an api transitive dependency) would be awesome!

Describe alternatives you've considered
For item 1, a simple extension function accepting a vararg/List of CallbackTokens that loops invoking each one should do.
For item 2 there's a draft at feature/extensions branch.
For item 3 it would probably be implemented like something in the following lines (I can be wrong, but I believe Kotlin allows to omit ):

// by now, inside of LiveCallbackRegistry interfaces:
fun LifecycleOwner.register(callback: Callback<I, O>) = register(lifecycle, callback = callback)

// maybe in the future, outside of the interfaces as top level extension functions:
context(LifecycleOwner)
fun LiveCallbackRegistry.register(callback: Callback<I, O>) = register(lifecycle, callback = callback)

Integrate Kover (possibly removing current JaCoCo implementation): https://github.com/Kotlin/kotlinx-kover
Enabling koverMerged feature would be a great plus, as new modules should be added soon!

Many PRs started failing without a noticeable reason