Handle HTTP errors more gracefully when performing a web view checkout

[sleroux]

At the moment, if the user encounters a loss of internet or some other kind of HTTP error they have no way to recover in the checkout process. A couple of options include:

1. Whenever the web view fails to load a web page, we can bubble that up to the Unity developer through the CheckoutDidFail callback.

2. Handle the HTTP error internally on the web view and build in a recovery mechanism.

Option (1) would give the Unity developer more control over what is happening in the checkout flow but would add more work on their side to implement the recovery mechanism. Option (2) would isolate any HTTP errors into the web flow and have them be self handled (maybe through a locally-injected HTML page with a refresh button and text). We could also combine both options.

At the moment I'm leaning towards option (2) so the Unity developer doesn't have to worry about it and keeps the API more simple.

[sleroux]

Here's an example of handling the HTTP errors within the web view (Option 2):

This is implemented by loading a local error HTML page into the web view when we fail to load the page. Tapping Reload will perform a browser refresh on the URL they were trying to access. I've also pulled in the Polaris styles to make it feel more Shopify-y.

@mikkoh Do you think this approach will suffice for handling network failures? We could also expose the HTML template to developers in the future if they want to customize it in some way.

I'm also assuming that failing to load a page is the extent of HTTP errors we would receive. Is there any other HTTP errors you can see us running into that isn't failing to load?

[mikkoh]

So here are some of my thoughts.

I like the approach of showing this page when there is an error. It would be cool to call the failure callback also so that the developer could handle it. But if we do that we also have to have the ability to kill the webview. Currently we don't have that capability.

I wonder about the copy. Shopify has a specific style of writing copy. Let me try to find someone who could give a look at it.

[sleroux]

It would be cool to call the failure callback also so that the developer could handle it.

Yea and even for logging purposes so the developer knows that the network was down.

I wonder about the copy. Shopify has a specific style of writing copy. Let me try to find someone who could give a look at it.

I was wondering the same thing. The message seems a bit too 'developer' 😉

[mikkoh]

Chatted with @biggeidea about the copy.

Here's what he said:

Hey. We usually need the following for an error message:

[10:36] 
What happened?
Where did it happen?
Why did it happen?
How does it affect me?
What should I do next?

[10:36] 
There should be a bit of guidance on Polaris as well. If you want to take a crack at a first draft, I can take a look and tweak it from there - just tag me in the GH issue

[sleroux]

What happened?

• Page was not able to load because the user has no internet connection. Where did it happen?
• Happened during a checkout. Why did it happen?
• User has no internet connection. How does it affect me?
• Checkout cannot be completed until internet is restored. What should I do next?
• Tap 'Reload' to try loading the page again

Here's an attempt:

Looks like you don't have an internet connection. You won't be able to continue checking out until you do. Tap 'Reload' to try loading the page again.

[mikkoh]

There might be other cases than internet being down. For instance lets say the API is down.

[sleroux]

We'll probably need to be more specific about the status code we get back from the web request. This would be good information to pass to the game developer but we might want to keep the UI the similar to the user. We might be able to display a generic user for API down/technical issues but show a more concrete error when we know the connection is offline.

[sleroux]

No network connection:

"Looks like you don't have an internet connection. You won't be able to continue checking out until you do. Tap 'Reload' to try loading the page again."

Generic catch all:

"We've run into an unknown issue. Tap 'Reload' to try loading the page again."

[sleroux]

Also to note:

For API down and other non-2xx status codes, the web view will handle it for us. Unfortunately we don't have access to the request's status code made inside the web view.

[sleroux]

This issue is invalid now that we're using Apple's SFSafariViewController for web checkout. It will handle bad connection states for us.

Any other HTTP error we might encounter from the checkout validation logic will be bubbled up through the failure callback we pass into the CheckoutWithNativeWebView call.

Marking as closed for now.