Description
Hello,
I'm using the MSDK v5 for various functionalities. As a modern android app we use Kotlin and coroutines for calls into the DJI SDK. For many of these calls we want work within coroutines, so we wrap them as suspend functions which implement suspendCancellableCoroutine but in many cases it's unclear how to handle cancelation cases.
Given DJI's architecture this has 2 forms.
Scenario 1 KeyInfo with callbacks:
suspend fun confirmLanding(): IDJIError? = suspendCancellableCoroutine { continuation ->
val key = FlightControllerKey.KeyConfirmLanding.create()
key.action(
onSuccess = { continuation.resume(null) },
onFailure = {
continuation.resume(it)
})
continuation.invokeOnCancellation {
//There is no API here for me to call so I can cleanup my listeners or abort
}
}
This is common across all of the different DJIKeyInfo types.
I know cancelListen() exists to cancel for Keys that use listen() but it's not clear if this is the appropriate approach for action, get, or set apis. Should I be using it in cancellation scenarios for all these other APIs?
Scenario 2 completion callbacks
There are many APIs that use CommonCallbacks.CompletionCallback
suspend fun enableSimulator(settings: InitializationSettings): IDJIError? { continuation ->
val callback = object : CommonCallbacks.CompletionCallback {
override fun onSuccess() {
continuation.resume(null)
}
override fun onFailure(error: IDJIError) {
continuation.resume(error)
}
SimulatorManager.getInstance().enableSimulator(settings, callback)
continuation.invokeOnCancellation {
//There is no API here for me to call so I can cleanup my listener
}
}
It's unclear how to handle this case for SimulatorManager, all of the APIs in the various RTKCenter modules, WaypointMissionManager calls, MediaManager's various pull calls, and on MediaItem pull calls as well.
I know this question is pretty broad so if you have any guidance for these scenarios, or future plans for improvements it would be helpful.