Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[android][expo-sharing] migrate to new modules API #20112

Merged

Conversation

alanjhughes
Copy link
Collaborator

Why

Migrate module to new modules API

How

Followed the usual steps involved in migrating a module

Test Plan

Tested in the bare expo app and all works as before. I removed onActivityResult as all it did was resolve the promise with null but I don't think this is necessary anymore with the new API. It can easily be put back if that was not correct.

@expo-bot expo-bot added the bot: suggestions ExpoBot has some suggestions label Nov 18, 2022
@expo-bot expo-bot added bot: passed checks ExpoBot has nothing to complain about and removed bot: suggestions ExpoBot has some suggestions labels Nov 18, 2022
Comment on lines -111 to -116
override fun onActivityResult(activity: Activity, requestCode: Int, resultCode: Int, data: Intent?) {
if (requestCode == REQUEST_CODE && pendingPromise != null) {
pendingPromise?.resolve(null)
pendingPromise = null
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, it looks great, but you can't just remove that function and resolve the promise earlier. The time when the promise will be resolved will be different.

Before:
js calls shareAsync -> intent is invoked -> share activity was opened -> user shares something -> execution goes back to the application -> the promise is resolved

Now:
js calls shareAsync -> intent is invoked -> promise is resolved

In many cases, the flow from the js perspective looks similar, because when the rn app goes to the background (when the shared activity is active), there is a small time window when the app code can still execute. However, it not always may be true.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I thought this mightn't be right. I'll put it back. So resolving with null is just a way of notifying the js that an action has been completed? You'd only need to do this in situations where it's some kind of callback? If it all completes inside the AsyncFunction body, you can just let the function complete without resolving if you are not returning anything?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, exactly. The AsyncFunction will automatically call promise.resolve(null) if the closure doesn't take the promise as an argument and the function is complete. In the case where a promise is the last argument of the function, you take responsibility for managing the promise itself. It's helpful when the function is completed, but the rest of the operation happens on a different thread.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, that makes sense, thanks Łukasz  👍

Copy link
Contributor

@lukmccall lukmccall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Greate, thanks for changes 🥇
I'll merge it as soon as all checks pass.

@lukmccall lukmccall merged commit a433170 into expo:main Dec 6, 2022
@alanjhughes alanjhughes deleted the @alanhughes/android/modules-expo-sharing branch December 6, 2022 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bot: passed checks ExpoBot has nothing to complain about
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants