WebView fallback

[PEConn]

Investigate providing a WebView fallback when the device does not have a TWA provider.

• Have a look at current usage.
• Consider APK size increase.
• Consider WebView Web API support.

Requirements for a WebView fallback:

• Opens startUrl in full-screen
• Supports multiple Origins
• Handles external navigations using CustomTabs
• New Intents should re-use an existing Activity / WebView
• Handle orientation changes so that page state isn't lost
• Handle onPause/onResume
• Handle onBackPressed
• Handle onSaveInstanceState
• Enable domstorage, database, etc.
• Splash screen support
• Immersive mode
• Sets android-app://<package-id> referrer.

[andreban]

On the normal flow, the browser will validate Digital Asset Links. In this case, everything is happening in the same application. Should the Support Library perform the validation in this case?

[bthecorgi]

This enhancement will be a great improvement for users. The current implementation can fallback to the user's browser. This causes a very jarring and disruptive experience. The content is loaded in the browser. Often times, this has many tabs opened. And switching back to the app (from app switcher) doesn't do anything (just shows homescreen).

[andreban]

I think an approach we can take here is to add a demo app that contains a WebView fallback. We can start with a naive implementation that will give us more understanding on what we will need to do to have solid implementation in the library and, once we are happy we can move the implementation there.

@PEConn, WDYT?
@b1tr0t, FYI

[PEConn]

Yeah, that makes sense - a demo people can copy and give feedback on, then potentially integrating it into the library.

…

On Fri, 18 Oct 2019 at 07:51, André Cipriani Bandarra < ***@***.***> wrote: I think an approach we can take here is to add a demo app that contains a WebView fallback. We can start with a naive implementation that will give us more understanding on what we will need to do to have solid implementation in the library and, once we are happy we can move the implementation there. @PEConn <https://github.com/PEConn>, WDYT? @b1tr0t <https://github.com/b1tr0t>, FYI — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15?email_source=notifications&email_token=AA4LBZKZXHTUS3XLTWX5IQDQPFMGXA5CNFSM4ITRYPM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBS6TTA#issuecomment-543549900>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4LBZORWGE3F4TBMXGREWLQPFMGXANCNFSM4ITRYPMQ> .

[andreban]

#46 kicked off a demo implementation. It's a naive implementation for now and more work is needed for it to be a good fallback implementation.

[naveedahmed1]

This would really help in improving overall user experience with TWA apps.

[strygo]

The WebView fallback sample is a good starting point, but there are aspects of it that need further functionality to bring the WebView experience closer to parity with TWAs:

• Handle orientation changes so that page state isn't lost
• Handle onPause/onResume
• Handle onBackPressed
• Handle onSaveInstanceState
• Enable domstorage, database, etc.
• The navigation bar color behavior doesn't seem right. As of now, the sample uses transparent, which is optimal for the splash screen but not what you'd expect when the WebView is shown

[andreban]

Yes, that's why we haven't added it as a default to the library yet. We haven't been able to come back to this yet. Any contributions to improve the WebView fallback demo will be greatly appreciated, as we intend to merge it into the Support Library.

[strygo]

OK. I am also experiencing an issue with audio playback that I haven't resolved. These are showing in the debug logs:

W/AudioManager: Use of stream types is deprecated for operations other than volume control
W/AudioManager: See the documentation of requestAudioFocus() for what to use instead with android.media.AudioAttributes to qualify your playback use case

[andreban]

What does the issue you are experience looks like?

One thing to keep in mind is that the WebView fallback will probably work on a best-effort to support PWA features - The WebView doesn't support all Web Platform APIs and, in many cases, feature detection also doesn't work as expected.

There's an interesting WebView for PWA implementation in this repo too, but I don't think it covers all the items you mentioned: https://github.com/wizeinsights/Android-PWA-Wrapper

[strygo]

I resolved my audio issue. After more testing, I discovered the device itself wasn't outputting any sound. It seems the Xiaomi Mi Box S is incompatible with certain TVs. I switched my display and audio is working.

Thanks for that link. I'll make other notes as I round out functionality.

[andreban]

@strygo Implemented most of the missing things. Not sure about this one though:

The navigation bar color behavior doesn't seem right. As of now, the sample uses transparent, which is optimal for the splash screen but not what you'd expect when the WebView is shown

The demo uses the color set in the AndroidManifes.xml. It is parsed in LauncherActivityMetadata here and used in the fallback here. Not sure I fully understand the issue. PS: the WebViewFallback doesn't have a Splash Screen.

[naveedahmed1]

@andreban awesome, great job 👍

Can you please guide how do we update our current TWA to incorporate this change?

[strygo]

Apologies. This may have been my issue - I was coming from a project derived from the earlier TWA sample. In that project, the navigation bar color was set to transparent. This caused issues when using the fallback WebView.

[andreban]

@naveedahmed1 Right now, the best source of information is the demo itself. We will move the fallback into the support library, which should make things easier. We probably won't enable it by default, but the idea is that it could be enabled with a flag. Probably with a warning that it's still experimental.

@strygo thanks for the confirmation!

[naveedahmed1]

Thanks for your reply @andreban .

How about integrating this in svgomg-twa? while it is added to the support library?

[andreban]

It will be integrated into llama-pack

[naveedahmed1]

That's awesome 👍

[strygo]

From my perspective, a few more items to consider for the WebView:

• Splash screen support (ideally rendered the same as when using TWAs)
• Send activity to background when you can't go back in the WebView (similar to TWAs I believe)
• An identifier included in the User-Agent header to indicate this mode (for TWAs, we rely on the initial Referer header, but I'm not sure that approach is possible here, if it is, that would be better)
• setMediaPlaybackRequiresUserGesture to false (I'm not sure TWAs do this, I think so)
• Support for earlier API levels (this required not setting status bar color on downlevel, and also handling the alternate signature for shouldOverrideUrlLoading)
• I noticed that we set our WebView to focusable = true and focusableintouchmode = true, not sure if this should be applied generally
• In cases where no browser exists at all (like Fire TV/Android TV), when a user opens an external link, you should ideally open another activity with a webview. Fortunately, we don't have this issue on our end, but I figured I would raise it for consideration

[andreban]

I've just added support for earlier APIs on the last PR.

Regarding Fire TV / Android TV, my guess is that developers should probably use store targeting to deploy a different APK that uses the WebView in those platforms. I don't know about Fire TV, but Android TV doesn't come with a browser. And Chrome can't be installed from the store.

I'll check out the best approach for the others.

[rulim34]

How about the WebView splashscreen? It just directly open the url without showing any splashscreen. on the WebView fallback.
And also how to do caching on WebView?

[Andrew67]

Hi @andreban ,
I've been trying to find some consistent information about the expectations around the android-app:// referrer, as it seems Firefox's TWA support is not populating it at all and I was thinking of bringing it up to them.
I'm seeing some conflicting information regarding the / at the end:

• Referrer added to WebView fallback, no /: https://github.com/GoogleChrome/android-browser-helper/pull/188/files
• Discussion about Chrome 81's change to add /: In chrome os the referrer is empty #64 (comment)

[andreban]

@Andrew67 thanks for catching this #191 adds a trailing slash to the WebView fallback. The trailing slash helps differentiate android-app://com.example/ from android-app://com.example.subdomain, so user-agents should add it.

[kudlav]

similar issue: #309