The current design does not support real async calls from JS to native since every call is blocked. In situations where you designed an async API such a call does not need to be blocking and drastically reduces performance if called multiple times in a row.
In addition to transit.invokeNative there should be a transit.invokeNativeAsync (not sure about the name) that puts a CallDescription into a queue and immediately returns void.
At a later point in time, the JS part looks at the queue and calls transit.doInvokeNativeAsyncCalls (again let's discuss this name) with an array of the current CallDescriptions in the queue. If the native runtime does not override this function, the fallback will simply iterate over the queued CallDescription, calls transit.doInvokeNative and discards the results.
A real native implementation will receive and iterate over all CallDescriptions in a single call. This way, there's no blocking for each call anymore. And since there's no result that needs to be propagated back to the JS one could even think of an async implementation on the native side
The current design does not support real async calls from JS to native since every call is blocked. In situations where you designed an async API such a call does not need to be blocking and drastically reduces performance if called multiple times in a row.
In addition to
transit.invokeNativethere should be atransit.invokeNativeAsync(not sure about the name) that puts aCallDescriptioninto a queue and immediately returnsvoid.At a later point in time, the JS part looks at the queue and calls
transit.doInvokeNativeAsyncCalls(again let's discuss this name) with an array of the currentCallDescriptionsin the queue. If the native runtime does not override this function, the fallback will simply iterate over the queuedCallDescription, callstransit.doInvokeNativeand discards the results.A real native implementation will receive and iterate over all
CallDescriptionsin a single call. This way, there's no blocking for each call anymore. And since there's no result that needs to be propagated back to the JS one could even think of an async implementation on the native sideAlso, see #12 for the opposite direction.