Exporting async functions from Android

[ide]

On iOS if the last two parameters of your RCT_EXPORT'd method are an RCTPromiseResolveBlock and an RCTPromiseRejectBlock, it will mark the exported method as an ES7 async function. When the JavaScript side of the bridge is set up, it knows it should define functions that return promises when it sees that some exported methods are marked as ES7 async functions.

The JS side is already done, so it's just some Java API design and code that needs to be written to get this on Android. I am not sure of the API right now. We could do a couple of things:

1/ Be like iOS and define two new types: ResolveCallback and RejectCallback. If we detect (via reflection) that the last two parameters of the exported method have these types, then we infer that it is an async function. Example syntax:

@ReactMethod
public void doSomethingAsync(String arg1, ResolveCallback resolve, RejectCallback reject) { }

2/ Add parameters to @ReactMethod. Same proposal as before but instead of using reflection, the programmer has to say something like this:

@ReactMethod(async = true)
public void doSomethingAsync(String arg1, ResolveCallback resolve, RejectCallback reject) { }

3/ Create a new annotation like @ReactAsyncMethod.

I prefer option 1 since it is consistent with RN iOS and because BaseJavaModule already uses reflection, but wanted to put a couple proposals out there. cc @mkonicek @kmagiera

Original iOS PR: #1232

cc @vjeux this is the last major piece of infra to making most of the codebase use async functions. The migration plan is pretty clear to me and can go into that w/more detail later.

[kmagiera]

I'd vote for the option (1) too

[kmagiera]

Any reason why can't we just use regular callbacks in native and have "promise" and "non-promise" version for every native method that takes callbacks as arguments?
It seems to me that the only difference is that we register those "async" methods with remoteAsync=true, so what if we could do that for every method that takes callbacks as an input? E.g. for the method RCTNetworking.sendRequest we can have one version that takes callback and also register RCTNetworkin.sendRequestAsync that would return promise but translate into the call to the same method on the native side. This way promises would be transparent for the bridge and we wouldn't need to change anything in native.
Is there any benefit for the native side to know that method is called using "promise"?

[ide]

Any reason why can't we just use regular callbacks in native and have "promise" and "non-promise" version for every native method that takes callbacks as arguments?

The main reason we did not do this on iOS was because many exported methods were inconsistent. Some took (errorCallback, successCallback) and others took (successCallback, errorCallback). Some methods took only one callback.

Also, we were able to use static typing for the callback arguments. The success callback must take only one argument (of any type). The error callback also takes only one argument, which must be a (nullable) NSError. These are the typedefs:

react-native/React/Base/RCTBridgeModule.h

Line 39 in 62e8ddc

typedef void (^RCTPromiseRejectBlock)(NSError *error);

.

[davidaurelio]

Implemented in b86a6e3. Methods are exported as async if they take a Promise as the last parameter. In Java, the object can either be resolved or rejected with the corresponding methods.