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

Implemented timeouts. #106

Closed
wants to merge 1 commit into from
Closed

Conversation

niothiel
Copy link

I believe timeout functionality would be a useful feature for this library. When interacting with a website, especially in a mobile context where internet connection is not guaranteed, there can be some causes where you can call a handler and never receive a callback.

This PR fixes that problem, allowing the bridge to return a timeout error as the response callback. This ensures that for every call into a webview that expects a callback, it will always get one.

@marcuswestin
Copy link
Owner

What happens if the JS calls the response handler after the timeout has occured? Looks to me like the app will crash:

        WVJBResponseCallback responseCallback = _responseCallbacks[responseId];
        responseCallback(message[@"responseData"]);
        [_responseCallbacks removeObjectForKey:responseId];

I'm hesitant to pull this. Here's my perspective: If you're interacting with a website through objc, you should be timing out the NSURLConnection. If you're interactive with a website through js, you should be timing out the request in the js. In this implementation, I believe the timeout has very little to do with network requests, and only to do with the amount of time it takes before the javascript responds.

Either way, I do see problems with the implementation as is, one of which I mentioned above. Let me know what you think in respond to these comments and we can take it from there.

Cheers, and thanks!
Marcus

@niothiel
Copy link
Author

Marcus,

Thanks for a well thought out response. Given your code snippet, that has already been taken care of by null-checking the responseCallback:

        if (responseId) {
            WVJBResponseCallback responseCallback = _responseCallbacks[responseId];

            if (responseCallback != nil) {
                responseCallback(message[@"responseData"]);
                [_responseCallbacks removeObjectForKey:responseId];
            }
        } else {

So if the response callback doesn't exist at this point, it was already timed out.

I thought about where the timeout should happen, and while you bring up a good point, I'm still convinced that it should happen inside the bridge. This is because there are certain cases where javascript-initiated navigation calls, such as iframe href changes could result in network errors, meaning that javascript will never reach that callback statement.

I know that not everybody will have the need for timeout calls, but I thought it would be a good addition to your library, and intentionally implemented it in a way to make them completely optional.

Let me know what you think!

-Niothiel

P.S. If you need a more in-depth example of where this comes in handy, just let me know!

@marcuswestin
Copy link
Owner

Hi @niothiel, unfortunately I think this shouldn't be baked into the library. It is easily implemented on top of WVJB and doesn't seem to be a feature that anyone else has needed.

Thanks for the PR though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants