Closed antonymarion closed 2 days ago
Agent comment from yating.liao in Zendesk ticket #110486:
I think it is unlikely for the SDK to modify this part of the logic. The mechanism where SDK callbacks represent the reception result of a command is quite common in wireless communication. The protocol used by drones maybe also follows a similar mechanism.
Communication between the SDK and the drone is also based on wireless protocols. When the SDK sends a command to the drone, the drone first responds whether it has received the command, and then its status changes. The SDK does not wait for the drone's status change because wireless communication resources are limited, and the drone and SDK cannot maintain a long connection for the same result. Therefore, the SDK uses a listening mechanism to allow the drone to actively push its status changes.
°°°
Ok got it.
It is a classical "I received your command and will handle it asynchronously" that returns all the promises in DJI's SDK.
and the limitation is wireless with long connection, makes sense
Agent comment from yating.liao in Zendesk ticket #110486:
I hope my response is helpful to you.
°°°
Hi Dji
Following the discussion https://github.com/dji-sdk/Mobile-SDK-Android-V5/issues/377 at the end of the ticket, I open this ticket since users should expect that the callback result of the SDK interface represent the execution result.
Otherwise promises can not be chained and it does not ease usage of the SDK.
The logic implemented here is event driven and using listeners.
Thus each call to the SDK should be followed by a listener on a dedicated event or a wrapper on this listener to create a Promise by ourself.