GoogleChrome / android-browser-helper

The Android Browser Helper library helps developers use Custom Tabs and Trusted Web Activities on top of the AndroidX browser support library.
Apache License 2.0
695 stars 289 forks source link

WebView fallback #15

Open PEConn opened 5 years ago

PEConn commented 5 years ago

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

Requirements for a WebView fallback:

andreban commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 < notifications@github.com> 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 .

andreban commented 4 years ago

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 commented 4 years ago

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

strygo commented 4 years ago

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:

andreban commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@andreban awesome, great job 👍

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

strygo commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

Thanks for your reply @andreban .

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

andreban commented 4 years ago

It will be integrated into llama-pack

naveedahmed1 commented 4 years ago

That's awesome 👍

strygo commented 4 years ago

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

andreban commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

andreban commented 4 years ago

@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 commented 2 years ago

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