Add a standardized way to send intents on Android

[ferrannp]

Introduction

As you know on Android, you can send intents to open other applications (including Settings), deep linking and more. For example, on Android P, if I was developing the Facebook application, I could give the user the option to open the following screen:

Using this intent:

Intent intent = new Intent(Settings.ACTION_CHANNEL_NOTIFICATION_SETTINGS);
intent.putExtra(Settings.EXTRA_APP_PACKAGE, packageName);
intent.putExtra(Settings.EXTRA_CHANNEL_ID, notificationChannelId);
startActivity(intent);

There is a library out there but only with specific cases https://github.com/lucasferreira/react-native-send-intent/blob/master/android/src/main/java/com/burnweb/rnsendintent/RNSendIntentModule.java (there are too many cases). And to be honest, I think this is quite important (core feature of the platform) to depend on an external library.

The Core of It

I think we should provide a standard way of opening intents in the core. Maybe it makes sense to have it in the Linking module?

Discussion points

• Should we add it as part of React Native? I think yes.
• Should be part of Linking module? I think yes but I don't have much knowledge of the core to be 100% sure.
• This change is Android only

P.S. I am working in a PR that should land soon so you can see it in action + code.

[axe-fb]

@ferrannp - I think this is a good idea, but it may be more useful if intents can be a part of the navigation system, instead of being a stand alone library. While it may make sense to be a part to linking, I think we should consider deprecating linking infavor of solutions provided by navigation libraries.

Maybe when we move Linking into the rn-community repo, it may make sense to expose this capability too.

[satya164]

I think we should consider deprecating linking infavor of solutions provided by navigation libraries

The Linking module is necessary to support deep linking and navigating to external URLs. JS based navigation libraries can't provide these features without the native Linking module.

[axe-fb]

The Linking module is necessary to support deep linking and navigating to external URLs. JS based navigation libraries can't provide these features without the native Linking module.

Sure, but it not need to live as a part of core. We could move Linking into rn-community. JS only navigation libraries could then depend on it. My point is that I am not sure if Linking has a use outside "navigation".

[hey99xx]

@axe-fb I don't know how much of Intent integration would be used by any navigation library. From what I see react-navigation tries to be pure-JS and scoped to internal app navigation, and Wix's react-native-navigation already has a lot of native code written to support a navigation api closer to OS standards. Neither of these navigation libraries gives extensive support for opening external apps to my knowledge.

If the Linking native code lives outside the core, then JS only navigation libraries still cannot directly depend on it. Instead they (JS only navigation library developers) will need to instruct the consumers of the library to also attach the native Linking library into their app. I don't think this is a preferable outcome for neither the app developers nor the navigation library owners who need to teach the community on how to attach native libraries. If you see this working differently I'd like to understand the flow you're currently proposing.

Also I wouldn't want to depend on a library in rn-community just to get the essential functionality that my app needs. FB chose this path while extracting the WebView component outside the core, but I don't think this model is necessarily applicable to something essential as deeplink support which should work out-of-the-box. I'd prefer the bare minimum to stay in the core in order to minimize beginners trying to integrate with 3P libraries with native code from day 1.

Then the question becomes where do we draw the line? From what I understand the OP sees the current Linking as insufficient, but integrating with something like react-native-send-intent may also bring lots of code that doesn't belong to the core (such as shareImageToInstagram).

We should consider also that each version of RN would only depend on a specific version of this library and you would not get new functionality at will without updating the RN version itself. As far as I understand, the flux of bug reports and feature requests Facebook was getting for the WebView component was one of the reasons for its extraction out of the core. Intent in Android serves a large range of functionalities such as opening activities, opening other apps' activities, sending and receiving broadcasts, picking file from the system; if we're not careful we may introduce a very similar problematic dependency here.

[brentvatne]

(JS only navigation library developers) will need to instruct the consumers of the library to also attach the native Linking library into their app. I don't think this is a preferable outcome for neither the app developers nor the navigation library owners who need to teach the community on how to attach native libraries. If you see this working differently I'd like to understand the flow you're currently proposing.

JS navigation libraries like react-navigation have all of their logic written in JS but we are happy to use native primitives outside of the core where necessary, for example react-native-gesture-handler and react-native-screens have become dependencies of react-navigation for our next major release. screens will be optional (but recommended), but gesture-handler will be required. In a future release, react-native-reanimated will also be required.

So, it wouldn't be such a significant burden for users to have to link a Linking library if it moves out of the core. Another approach we could take here is to move Linking out of core but install it by default in the react-native init template, or provide another 'standard library' kind of template that includes it. If the user really doesn't want to learn how to do any of this they can also just use Expo.

[ferrannp]

I have a PR almost ready to send with this proposal (hope to send it this week). If then you would like to talk about having a separated module from the core (let's say react-native-linking) on react-native-community and you are looking for a mantainer, we can discuss that :)

[ferrannp]

This is merged facebook/react-native#22302. We can talk in separate issue about extracting Linking out of core.

[omerdn1]

This feature is not on master and I can't find any trace of it.
What happened to this feature?

[matt-oakes]

@omerdn1 It is in master here https://github.com/facebook/react-native/blob/master/Libraries/Linking/Linking.js#L98-L110 I'm not certain if this has made it into a release yet though. If not, it will be in the 0.60 release.