Ios scheme handler

[ccorcos]

This PR is on top of #158 and #173. Also in response to #135.

Its lacking in documentation in the README but the types are all there and more explanation here: ccorcos#1.

Basically, scheme handlers and intercepting requests in the webview is full of quirks. Things like the body data doesn't go through on POST requests and CORS requests don't work on Android when serving from a URL scheme.

The goal here is to be able to intercept requests, in my case for serving cached files, but there's all kinds of things you can do with this. Here's how it works...

On iOS:

function App() {
  return (
    <WebView
      source={{uri: "myapp://example.com"}}
      urlScheme="myapp"
      onUrlSchemeRequest={async ({url, method, headers}) => {
        // You can make a requests and return your own response.
        return {
          type: "response",
          url,
          status: 200,
          headers, // response headers, not request headers.
          body: "" // response body. optional.
        
        }

        // You can manipulate the the request if you want and the native code
        // will execute the request and pipe it back to the native webview.
        return {
          type: "redirect",
          url, 
          method, 
          headers, // request headers.
          body: "" // request body. optional.
        }

        // You can return a path to a local file and the native code will serve this
        // file for you complete with response headers.
        return {
          type: "file",
          file: "/absolute/path/to/file.ext", // Recommend using react-native-fs
          url,
          headers, // response headers, not request headers.
        }
      }}
    />	
  )
}

On Android, we simply override the the http and https url scheme and let you specify the base intercept url. But the rest of the behavior is the same.

function App() {
  return (
    <WebView
      source={{uri: "https://example.com"}}
      baseInterceptUrl="https://example.com"
      onUrlSchemeRequest={async ({url, method, headers}) => {
        // Same as iOS
      }}
    />	
  )
}

I know this is a little bit lacking in some places...

1. I'm not feature flagging properly for iOS 11 and I'm sure there's some gradle versioning stuff for everything to work properly. Believe it or not, we're not native app developers so we're just winging it.
2. There's a lack of documentation in the README to make this feature discoverable.

I have to move on and work on other things but if someone is willing to help get this across the finish line, I'm happy to help.

[jamonholmgren]

This looks really good @ccorcos . Well done for a "not native app developer". :)

We'll wait until it is more mature and people have used it a bit before reviewing, testing, and merging. So, basically, let's hang onto this PR and see whether it's useful to people

[jamonholmgren]

@ccorcos Can you resolve conflicts and update to master?

[ccorcos]

@jamonholmgren I'll try to get around to this soon.

[harrisrobin]

hey @ccorcos , would love to test this! Looks great, let us know when you get a chance to resolve the conflicts 😄

[RangerMauve]

Would it be okay if I did a new PR with the merge fixes?

[Titozzz]

@RangerMauve You can start from his branch, I don't think he would mind that.

[adbs1]

Hi @RangerMauve, have you got an active plan to merge commit some merge fixes?

[RangerMauve]

I think I have it working in this repo

I've had to put my work on it on pause though. 😅

edit: updated link URL

[ccorcos]

I haven't had time to get around to this but I'm happy to check out your PR @RangerMauve

[RangerMauve]

@ccorcos I think it's about as functional as it'll get. I stopped using it because the performance of the thing I was trying to do was awful and requests kept timing out. 😅

[ccorcos]

Interesting. What were you trying to do? It's working pretty well for me right now in our app.

…

On Mon, Mar 18, 2019 at 10:36 AM RangerMauve ***@***.***> wrote: @ccorcos <https://github.com/ccorcos> I think it's about as functional as it'll get. I stopped using it because the performance of the thing I was trying to do was awful and requests kept timing out. 😅 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#209 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABth3-uheIlEAqp8GeP6IIz1osOb4mOIks5vX866gaJpZM4ZSP4K> .

[RangerMauve]

I'm trying to load content from the dat protocol: https://github.com/RangerMauve/datmobile

I don't think it's a problem with the changes to react-native-webview, it's entirely a problem with getting dat working in react-native being slow. 😅

[ccorcos]

Interesting. Receiving binary data shouldn't be too bad -- I'm proxying imaging just fine. But uploading binary data is going to be slow.

…

On Mon, Mar 18, 2019 at 11:03 AM RangerMauve ***@***.***> wrote: I'm trying to load content from the dat protocol: https://github.com/RangerMauve/datmobile I don't think it's a problem with the changes to react-native-webview, it's entirely a problem with getting dat working in react-native being slow. 😅 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#209 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABth3-Pp9_WvHuIEKFoeNJS_1ZM7AddIks5vX9UAgaJpZM4ZSP4K> .

[RangerMauve]

The problem is that doing cryptography / file access / peer discovery in the RN thread is really slow, so by the time the content is ready to be served to the webview, the request has already timed out.

[ccorcos]

@jamonholmgren @harrisrobin @Titozzz @RangerMauve @rbscott I've created a new PR that is rebased on master. Still some work left to do before merging, but I'm hoping to take this across the finish line this time. #784