Hi, I've been working on my multiplatform library ...

# getting-started

[Ishlahul Hanif]

Hi, I've been working on my multiplatform library for quite some times now
The nature of this library is basically to feed data back to the user every 5 sec (for example), but I don' want the user/caller to be concerned about this 'routine'. Since the fetching task should run on background, I'm planning to use coroutine for this task.

this is the simplified version of the implementation:

public fun startWatch() {
    // check if the job is already running
    if (job.isActive) {
        println("Coroutine task is already running.") 
        return
    }

    // get new value from remote & update existing array
    fetchAndUpdate()

    // launch coroutine that periodically get and set value
    coroutineScope.launch {
        delay(FETCH_DELAY_DURATION_MILLI_SECOND) // for example, 5 sec
        fetchAndUpdate()
    }
}

private fun fetchAndUpdate() {
    // get new value from remote
    val newValue = remoteProvider.getValue()
    internalMem = newValue
}

public fun getValue(): Values {
    return internalMem
}

if possible, I don't wish the caller of getValue() nor startWatch() is concerned about coroutine, and just care about the value they would get

the user/caller only need to startWatch() and then use getValue() when they need the value

my question:
1. is running a coroutine in library acceptable? if not, how should Implement the 'background schedule' behaviour?
2. is there anything I should be aware of regarding atomicity if this function is called in multiple thread? should the internalMem be atomic? I'm not sure because the value should only be changed every 5 sec, and most of the time the old value would still be reliable
3. is there any threading annotation I should mark?
many thanks guys!

[CLOVIS]

I recommend you read this article: https://arrow-kt.io/learn/resilience/retry-and-repeat/

W.r.t your questions:

is running a coroutine in a library acceptable?

Yes, but the user of the library should control its lifetime.
There are two main cases:
• "the user may want to stop the operation, e.g. when the user goes to another screen that doesn't use the library" → take a Job as parameter, and ensure all background tasks you start inherit from it (example: tasks started using the CoroutineContext from the caller, so only the Job is necessary).
• "the user may want to control the thread pool, the delays, etc" → take a CoroutineScope as parameter (example)

is there anything I should be aware of regarding atomicity if this function is called in multiple thread?

It really depends what you're doing. In general, shared mutable state is bad: it's better to have a coroutine with the only purpose of storing the value, such that it's never mutable from everywhere else.

is there any threading annotation I should mark?

No, coroutines do not require threading annotations, since those are for protecting shared mutable state, and we don't have any 🙂

[Casey Brooks]

if possible, I don’t wish the caller of getValue() nor startWatch() is concerned about coroutine

Users of the library would likely find this more frustrating than helpful. I’d recommend making startWatch take a CoroutineScope parameter, so users are fully aware that it’s running in the background, and can customize it it needed.

Likewise, I’d store the value in a StateFlow so it’s clear to users that the value might be updated over time. They can then opt-in to reactivity by collecting the flow, or they can just use stateFlow.value to get it immediately