Enables communication between the webview and RN

[odino]

Android devs have been relying for ages on intercepting custom HTTP
calls made by the webview, to map them to native actions,
like here.

Say that we have a "close" button in our web interface. We first detect
if we're running on web or within a webview -- if on web, we simply call window.close().
If we're running within the app things get a bit more complicated, but we can
simply call app://exit and the app will be able to intercept this call and
close the webview for us.

Now, this PR adds the ability of doing it on RN. You basically specify a
protocol for messages that should be forwarded to RN (ie. rn) and then,
when your webview loads a resource from rn://xyz the onMessage callback
will be called. You can access the URL etc etc through event.nativeEvent.url.

Example:

let onMessage = (event) => {
  let {url} = event.nativeEvent;

  if (url.endsWith('exit')) {
    BackAndroid.exitApp(); // just sayin'...
  }
}

return <Webview
  source={...}
  messageProtocol={'myApp'}
  onMessage={onMessage}
>

Or something of that sort. Communicating between the webview and RN / the ability
to intercept resources loaded within the webview has been already discussed but I
feel we need a very simple implementation rather than creating a full-blown
messaging pattern which will just hurt (maintainability, complexity) in the long run.

Also, my Java is pretty rusty ;-)

[facebook-github-bot]

By analyzing the blame information on this pull request, we identified @odino, @mkonicek and @nicklockwood to be potential reviewers.

[odino]

My biggest doubt here is that this guy is android-specific. I think we already have something working on IOS so I would prefer to see both working in the same way. Anyhow, let me know what you guys think.

[odino]

Saw @astreet comments on #6478 (comment) and I agree that regex patterns might be a good, viable solution. Though, what if we need to run cb when a pattern is matched?

[mkonicek]

Is this Javadoc correct?

[odino]

nope, sorry -- copypasta :)

[mkonicek]

In the example, you have: messageProtocol={'myApp'}. Does the WebView load a myApp:// URL? Can you provide a full example please?

[mkonicek]

Saw @astreet comments on #6478 (comment) and I agree that regex patterns might be a good, viable solution. Though, what if we need to run cb when a pattern is matched?

Can you elaborate please? What do you mean by "what if we need to run cb when a pattern is matched?"?

[odino]

This is what I meant -- we could pass some object like this:

let routesToIntercept = {
  'myApp://some-action': () => console.log(123),
  'myApp://*': () => console.log(456)
}

return <Webview
  routesToIntercept={routes}
/>

and run the cbs based on the route we intercept. But I'm not 100% sure on how to do it in RN -- I might need some help / hints there.

The problem I see with my PR is that IOS / android implementations will vary quite a bit, which sucks. So Im open to consider changing the implementation in favor of something that can work longer term. Let me know your thoughts.

[facebook-github-bot]

@odino updated the pull request.

[facebook-github-bot]

@odino updated the pull request.

[stereodenis]

@odino https://github.com/alinz/react-native-webview-bridge

[odino]

@stereodenis that wont work for legacy implementations that are based on calling custom URLs :) even though I think it's a good solution I was aiming at taking care of the practice of using custom URLs since there's a lot of android + webview implementations that use that method.

[ghost]

@mkonicek would you mind taking a look at this pull request? It's been a while since the last commit was reviewed.

[stereodenis]

@odino will it be replacement for react-native-webview-bridge?

[odino]

@stereodenis well, I would like to see a default way to implement some sort of communication between webviews and RN :)

[stereodenis]

alinz/react-native-webview-bridge#109

[mkonicek]

Sorry for the delay on reviewing this - there's now a related proposal using postMessage: #9762

[lacker]

Since the postMessage change is accepted with #9762 I think this pull request has been superceded. I'm going to close this PR but please feel free to reopen if this is hitting a different use case or has an independent rationale.