Open PEConn opened 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?
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).
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
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 .
This would really help in improving overall user experience with TWA apps.
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:
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.
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
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
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 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 awesome, great job 👍
Can you please guide how do we update our current TWA to incorporate this change?
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.
@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!
Thanks for your reply @andreban .
How about integrating this in svgomg-twa
? while it is added to the support library?
It will be integrated into llama-pack
That's awesome 👍
From my perspective, a few more items to consider for the WebView:
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.
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?
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:
/
: https://github.com/GoogleChrome/android-browser-helper/pull/188/files/
: https://github.com/GoogleChrome/android-browser-helper/issues/64#issuecomment-656063101@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.
Investigate providing a WebView fallback when the device does not have a TWA provider.
Requirements for a WebView fallback:
startUrl
in full-screenandroid-app://<package-id>
referrer.