android-browser-helper icon indicating copy to clipboard operation
android-browser-helper copied to clipboard
verified publisher icon GoogleChrome

WebView fallback

Open PEConn opened this issue 6 years ago • 24 comments

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:

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

PEConn avatar Sep 04 '19 13:09 PEConn

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?

andreban avatar Sep 06 '19 06:09 andreban

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).

bthecorgi avatar Oct 17 '19 19:10 bthecorgi

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

andreban avatar Oct 18 '19 06:10 andreban

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 < [email protected]> 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 https://github.com/GoogleChrome/android-browser-helper/issues/15?email_source=notifications&email_token=AA4LBZKZXHTUS3XLTWX5IQDQPFMGXA5CNFSM4ITRYPM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBS6TTA#issuecomment-543549900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4LBZORWGE3F4TBMXGREWLQPFMGXANCNFSM4ITRYPMQ .

PEConn avatar Oct 18 '19 09:10 PEConn

#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.

andreban avatar Dec 13 '19 11:12 andreban

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

naveedahmed1 avatar Feb 14 '20 09:02 naveedahmed1

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

strygo avatar Mar 02 '20 17:03 strygo

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.

andreban avatar Mar 02 '20 17:03 andreban

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

strygo avatar Mar 02 '20 17:03 strygo

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

andreban avatar Mar 02 '20 17:03 andreban

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.

strygo avatar Mar 02 '20 18:03 strygo

@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.

andreban avatar Mar 09 '20 13:03 andreban

@andreban awesome, great job 👍

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

naveedahmed1 avatar Mar 09 '20 14:03 naveedahmed1

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.

strygo avatar Mar 09 '20 14:03 strygo

@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!

andreban avatar Mar 09 '20 15:03 andreban

Thanks for your reply @andreban .

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

naveedahmed1 avatar Mar 09 '20 15:03 naveedahmed1

It will be integrated into llama-pack

andreban avatar Mar 09 '20 15:03 andreban

That's awesome 👍

naveedahmed1 avatar Mar 09 '20 16:03 naveedahmed1

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

strygo avatar Mar 09 '20 17:03 strygo

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.

andreban avatar Mar 09 '20 17:03 andreban

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?

rulim34 avatar Apr 29 '20 05:04 rulim34

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 /: https://github.com/GoogleChrome/android-browser-helper/issues/64#issuecomment-656063101

Andrew67 avatar Oct 03 '20 17:10 Andrew67

@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.

andreban avatar Oct 04 '20 07:10 andreban

similar issue: https://github.com/GoogleChrome/android-browser-helper/issues/309

kudlav avatar Mar 10 '22 07:03 kudlav