Progressive Web App (PWA) redirect page into standalone mode - google-chrome

I have PWA and I can run it as standalone (if user clicks icon on a device) or I can run as normal website (if user enter URL directly into web browser).
Is it possible to redirect page (open as standalone) if user open it as non standalone?
My manifest file already contain standalone parameter:
"display": "standalone"
I need something to start with.

As far as I know you need to "install" the pwa on the user device first.
By clicking the icon on the device (meaning you already installed the app there) you open the PWA that will be rendered as described in the web manifest (standalone in your case).
If you wouldn't have already installed the pwa on the device, you would have the same behaviour you are getting on your desktop by accessing the web site with the browser.
Let me know if I misunderstood your question.
UPDATE
The answer to your question (in the comment) is no (from a desktop browser). Chrome on an Android device uses/opens directly the PWA version, if installed of course. This is due to the Android Intent Filters that enable this.
But this is not the case from a desktop browser, where the user accesses the web site by entering the url manually. Maybe in the future it might change, but at the moment it is not possible.

In Chrome on desktop, if the PWA is installed and the user opens the app in the browser, there's a "To open this link, choose an app" link at top right on the address bar, between the password manager key and the bookmarks star - you could point that out to the user. Clicking that link offers a button to open the PWA and close the browser tab.

Related

Minimum Chrome version for TWA - options?

I have a Trusted Web Activity app that is displaying a Progressive Web Application by using the Android Browser Helper. The documentation and code indicates that the mobile app only runs properly when the Chrome Browser is 72 or above. The address bar is visible when the Chrome Browser is outdated. I believe I have the option of a Webview-fallback but I prefer not to use Webview as some of the app's functionality is incompatible with Webview.
While testing, when the Chrome Browser is updated on the same device, the trusted web activity runs without any issues.
What options do I have where the address bar isn't visible?
Is the min SDK the only way to set the minimum browser requirements or can I explicitly set a min Chrome Browser version in the Play Console for the app before the user downloads it? (which prompts the user to update the browser before installation)
Thanks in advance!
It's not possible to set a browser version requirement on the Play Console.
Besides falling back to a WebView, or showing the application with the URL bar, the other solution would to block the application from loading and ask the user to update / install a browser that supports Trusted Web Activity.

What is the difference between Chrome App Shortcuts and Desktop Progressive Web App (PWA)?

When I create a Chrome App Shortcut using ... > More Tools > Create Shortcut...
it creates a Shortcut that I can pin to Start, to Taskbar or to Desktop.
When I install a Desktop Progressive Web App (PWA) it does the same.
I know that PWA have some special features like Notifications, Offline Support, etc..
My question is: regarding Windows System, are they both just shortcuts?
For creating Chrome App Shortcuts after following the steps, this does indeed create a shortcut on the desktop. But it no longer uses the favicon and it opens in a regular chrome window alongside all other chrome windows. Shortcuts aren't the same as PWAs. A shortcut opens it in a Chrome window, in a new tab. A PWA opens in it's own window, as a separate app. They are more like Chrome Web Apps when they had those in the app store, except now you don't have to go to the app store to get them. Check this blog for more details.

“App banner support” in Chrome Devtools

Where is the "App banner support" setting for progressive web app installation in Chrome Canary 55?
Per this guide, I'd like to test whether the web app install banner is working correctly on my site.
The article shows its possible to test using the Chrome devtools mobile panel...
Here are his instructions:
If you don’t see the “Request app banner…” entry, try the following:
Update Chrome to the latest version
Enable the flag for “Devtools Experiments”
chrome flags enable-devtools-experiments and restart Chrome
Enable the option “App banner support” in Devtools -> Settings -> Experiments (If you don’t see it, press Shift six times there to get all experiments)
Enable the flag for “Add to shelf”
chrome://flags/#enable-add-to-shelf
So, I enable the flags, open the devtools, press shift x6 and I don't see anything in here about "App banner support".
The tutorial you mention is relatively dated, and the feature has since been moved and graduated from being a DevTools experiment.
Chrome 53/55 DevTools has an Application tab with an Add to homescreen link, which triggers the app-install banner if your app meets the criteria outlined below (errors logged to console):
Screenshot of install banner on Chrome 53/55, macOS Sierra:
Screenshot of install banner on Chrome 54, Android 6.0.1:
More recent (updated 6-Oct-2016) documentation on Web App Install Banners states:
Chrome automatically displays the banner when your app meets the following criteria:
Has a web app manifest file with:
a short_name (used on the home screen)
a name (used in the banner)
a 144x144 png icon (the icon declarations must include a mime type of image/png)
a start_url that loads
Has a service worker registered on your site.
Is served over HTTPS (a requirement for using service worker).
Is visited at least twice, with at least five minutes between visits.
Testing the app install banner
The app install banner is only shown after the user visits the page at least twice within five minutes. You can disable the visit-frequency check by enabling the Chrome flag #bypass-app-banner-engagement-checks. To test on desktop Chrome, you need to enable the Chrome flag #enable-add-to-shelf.
Then, as long as you have a manifest (configured correctly), are on HTTPS (or localhost) and have a service worker, you should see the install prompt.

Hide Web App's URL Completely in Chrome

Is it possible to create a Chrome shortcut that will launch a web app in such a way that users will not be able to view or access the URL of the web app via Chrome, e.g., via the address bar, status bar, developer tools, etc. If not, would it be possible if I packaged the web app as a Chrome app? I should note that I am not concerned about the shortcut itself containing the URL, e.g., in its "Properties", because I already have an executable will which launch the shortcut. All I care about is the user not being able to view the app from within Chrome itself once the app has been launched, at least not easily.
I have tried adding Chrome flags/switches, namely, kiosk mode, fullscreen mode, and app mode, but none of them work 100% as needed. Kiosk and fullscreen modes will launch as such only if no other instances of Chrome are open; if another instance of Chrome is already open, both modes will launch in a regular view mode in which users can see the URL in the address bar. App mode (I added "--app=http://www.example.com" to the end of the "Target" property of the shortcut) is promising because it launches with no browser chrome, but I notice that if I refresh the page while in app mode, I can see the URL both in the top window bar and the bottom-left status bar. Also, app mode doesn't prevent the user from opening Developer Tools, which makes viewing the URL trivial.
Any ideas welcome!

URL to open iOS app in App Store web page and iTunes app simultaneously

What is the preferred URL to use to open an iOS app in it's App Store web page as well as the iTunes app (when available on the host device)?
I've tried using the itms:// protocol but this opens the app details in the iTunes app only and so is of no use when the URL is navigated to from an Android or Windows phone for example.
I believe you would want to look at the browser to determine which link to use. If the browser is Safari on iOS device, give them the iTunes protocol link, otherwise, http://.
I believe javascript allows you to read such information: Take a look here: http://www.w3schools.com/js/js_browser.asp
I've discovered that the behaviour of a URL opening an iTunes preview web page before automatically opening the iTunes app on the host device (where available) is triggered by affiliate links (which need to track the click before taking the user to the intended destination).