I've made a small PWA in RoR; following and I followed Google's guide on having "Add to Homescreen" banners. Everything in devtools is fine: the service worker is registered, the manifest.json is found, the "Add to Homescreen" link is displayed and runs in the tool drawer.
I even installed Lighthouse like they said and ran the report; it says everything should work. However, I have yet to see the banner (yes, it isn't already on my homescreen; yes, I visited at least five minutes apart).
Does anyone have an idea on what the threshold is WRT users activity to make the banner appear?
(ps. does anyone want to try it out here?)
There's actually a google chrome flag for bypassing those engagement checks, it's called "Bypass user engagement checks".
So you'll need to go to chrome://flags, then find that flag, enable it, and then restart chrome.
The banner should show up every time once that flag is enabled, assuming everything is in line with your manifest.json and service worker.
I saw you referenced two manifests on your page:
Line 20:
<link rel="manifest" href="/manifest.json" />
Line 27:
<link rel="manifest" href="/assets/favicon/manifest-71676a3789f8b2a25498b2271ddc3288b14553d94e25c37030e6d69d46d72b81.json" />
When I frist load the page I see the mainfest definition in chrome dev tools, but when I reload the page the manifest is gone.
thanks for the responses; I waited like a day, cleared my caches completely, and got the banner. I still don't know the threshold for how many times you have to visit, but at least it works.
Related
We were surprised we didn't find any mention of this anywhere online, so we're posting here in hopes we find a solution.
Using an iPhone with mobile safari is when we hit this issue running the 2 easy to follow tests below, one works, one doesn't.
Here is the link
https://pwa-react.netlify.com/
Here are the 2 tests we run (both listed in the link), one works when not in PWA mode, and the other fails when in PWA mode.
Test #1: Works Perfectly (Expected Behaviour)
Visit https://pwa-react.netlify.com/ from iPhone in mobile safari
1. Make sure you have google drive on the phone but not logged in.
2. Click "Choose File". It will show you the list of options to choose from.
3. Click "Browse" to look for the photo.
4. Click "Cancel" and you're back here.
5. Click "Choose File" it will still show you the list of options to choose from.
This works perfectly in mobile safari but NOT in PWA mode below.
Test #2: Does NOT Work (Unexpected Behaviour) (PWA)
Visit https://pwa-react.netlify.com/ from iPhone in mobile safari, hit the share
button, then add to home screen. This will add the PWA app on your phone. Open App.
1. Make sure you have google drive on the phone but not logged in.
2. Click "Choose File". It will show you the list of options to choose from.
3. Click "Browse" to look for the photo.
4. When it shows you the Google Drive logo with Sign In, double click the home
button, then go back to the PWA.
5. Click "Choose File" it will NOT show you the list of options to choose from.
This is now 100% broken.
The ONLY way to fix it is to go to Settings>Safari>Clear History and Website Data (all the way down)
How can we fix this so when the user hits "Choose File" it shows the list of
options to choose from in the PWA?
Screenshot #1: These are the options that appear in Test #1 and stop appearing in Test #2
Screenshot #2: This screen allows us to cancel in Test #1 but it disappears in Test #2
Any idea how to get Test #2 to work by allowing us to choose the upload options like in Screenshot #1 without breaking the app and having to go to safari settings to clear history and website data for it to function again?
PS - Here is the repository file pwa-react/src/App.js
We were facing almost exactly the same issue in our PWA, so first, off I want to thank you for helping us narrow down the cause.
After reviewing the iOS PWA lifecycle (article here) and a couple maddening hours of trial and error I was able to figure out a solution that is semi-acceptable.
My guess at what is happening when you leave the app mid-upload (Test #2) is that there is some internal context in how iOS handles PWA's that is not being reset, so when you go back and try to upload a file again it thinks that the upload dialog is already open.
The article mentions that opening external links without target=_blank will cause the PWA context to be deleted, so when the in-app browser closes, the PWA page reloads in the standalone window. I thought that might reset the "detached upload" context, and it ended up working.
So I created a page hosted on another domain, and linked to it below our upload button in the PWA:
// not sure the target={'_self'} is necessary but not risking it
<a href={'https://externalDomain.com/reset'} target={'_self'}>
Having Issues? Reset Upload
</a>
This works decently well, minus one issue. When you click this link it opens the in-app browser, but there is no "Done" button or navigation tools for the user to know how to exit. Linking back to the PWA does not work, because iOS detects that and does not reset the app context. What I did notice was that if I navigated to another page from the first external page (I originally just tested this with google.com), the "Done" button would show up, making it obvious how to exit.
With that knowledge, I guessed that you could probably just do window.history.pushState to achieve the same effect, which works. My final solution is below. It causes the entire app to reload when the user presses Done from the in-app browser, but that's far better than having them re-add to the home screen in my opinion.
const Reset: React.FC = props => {
React.useEffect(() => {
// Redirect any wayward users who find this page from outside the PWA
if (!window.matchMedia('(display-mode: standalone)').matches) {
navigate('/');
}
// push an additional page into history
const newUrl = `${window.location.href}?reset`;
window.history.pushState({ path: newUrl }, '', newUrl);
}, []);
return (
<Grid container>
<ArrowUpIcon />
<Typography variant={'h5'}>Press done above to return to App</Typography>
<Typography variant={'body1'}>Sorry for the inconvenience!</Typography>
</Grid>
);
};
Hope this helps! Would love to hear if it works for you.
Edit After Production Testing:
An additional important note is that your "reset" page must be on a completely different domain for this to work. Ran into this today in production, because our reset page was on a subdomain with the same root as the PWA, iOS was not resetting the entire PWA lifecycle.
SUMMARY
Key Issues:
Leaving an iOS PWA while any of the "file upload" dialogs are open ('Take Photo', 'Photo Library', or 'Browse') breaks the iOS PWA lifecycle.This breakage makes it impossible for the user to open any "file upload" dialogs when clicking on a file input.
In order to fix this issue, the PWA context must be completely reset.
It seems that the only ways to reset the PWA context are to restart the phone, delete the app and re-add it to the home screen, or to open an external link.
When opening an external link, the "Done" button that closes the iOS PWA embedded browser will not show on the initial page. The user must navigate to an additional external page in order for the "Done" button to show.
External links do not trigger a reset of the PWA context reset when they have target="_blank".
Solution:
In order for the user to be able to upload files again, the PWA context must be reset. The easiest way to do this (in my opinion) is to ask them to open an external link.
(In PWA): Present a link to the user to fix the fact that the upload dialog is not showing. The link destination must be a completely unrelated domain (not a subdomain) and must have target="_self" (issue #5).
(External Page): Once the user clicks on the link and the external page opens, there will be no visible way to leave the page (issue #4). To resolve this, you can use history.pushState to simulate navigating to an additional page.
(External Page - Bonus): To make it clear to the user that the issue has been resolved, add an arrow in the top left pointing to the "Done" button (as shown in my screenshot).
I am trying to set up App Links so that:
a) When I tap on a link on the Facebook app, it opens my app if installed
b) If not installed, Facebook should not prompt the user to be directed to the App Store, and instead open the link in the in-app browser
I have been experimenting with the al:web:should_fallback meta tag, but there have been some mixed results:
When al:web:should_fallback is set to false, scenario a) as above works correctly, as expected. Scenario b) is not fulfilled, as expected, because I've indicated that the system should not fall back to the web.
However, when setting al:web:should_fallback is set to true, even though the app is installed, scenario a) no longer works.
Why is this? I am under the impression that al:web:should_fallback controls scenarios for when the target app is not installed
Some setup details:
My website's meta tags are as follows (Actual values replaced by "_"):
<meta property="al:ios:app_store_id" content="_" />
<meta property="al:ios:app_name" content="_" />
<meta property="al:ios:url" content="_://_" />
There are no outstanding warnings on the OG Debugger
There is only one warning on the App Ads Helper, and this relates to Deferred Deep Linking, which according to the App Links iOS documentation, is no longer supported
Any insight would be greatly appreciated!
I have found one related question: Cannot get the new AppLinks to work on iOS or Android But I am not sure if it is entirely similar with the problem that I am facing. Thus, I created this question.
If I understand correctly from: https://developers.facebook.com/docs/applinks/ios
When I click on a proper applink with the proper meta data:-
Case 1: I have the app installed:
Expected Action 1: It will navigate to the specific page inside the app.
Case 2: I do not have the app installed:
Expected Action 2: It will direct me to the app store page of the app to download.
Here are the configurations that I have done so far:-
The App Link URL: http://watchoverme.parseapp.com/
The App Link Meta Data:
<html>
<head>
<title>Watch Over Me</title>
<meta property="al:ios:app_store_id" content="431208868"/>
<meta property="al:ios:app_name" content="Watch Over Me" />
<meta property="al:ios:url" content="watchoverme://promotion" />
<meta property="al:web:url"
content="https://itunes.apple.com/app/id431208868?mt=8" />
</head>
<body>
Yo!
</body>
</html>
On the app side, I have added the custom url scheme like the screen shot below:-
So far, I have tested a few scenarios below:-
Scenario 1: I created another simple app with a single Button to open the applink.
The code for the button:-
- (IBAction)appLinkTapped:(UIButton *)sender {
NSLog(#"appLinkTapped");
UIApplication *app = [UIApplication sharedApplication];
NSString *path = #"watchoverme://promotion";
NSURL *ourURL = [NSURL URLWithString:path];
/*
if(![app
canOpenURL:ourURL]){
path = #"http://watchoverme.parseapp.com/";
ourURL = [NSURL URLWithString:path];
}*/
[app openURL:ourURL];
}
Result 1: If I have the WatchOverMe app installed and I tap the button, I can open the WatchOverMe app. Great!. But if the WatchOverMe app is not installed and I tap on the button, nothing happens. Should I be directed to the iTunes App store to download the app? Or I did something wrong?
Scenario 2: I posted the link (http://watchoverme.parseapp.com/) on Facebook and try to tap on the link on my mobile.
Result 2: Whether I have the app installed or not, it only shows me the blank website.
The question: Am I missing something here on the configurations until it can not trigger the expected applink behavior above?
Thanks
Update #1
Thanks Ming Li for pointing me to the right direction. I want to understand better on how app link works. So, I have done more testings and here is what I have found:-
From the the screen shot above:
Case A: I share the app link using the Watch Over Me app (you will see "via Watch Over Me")
Result A: When I tap on the link on the Facebook App. If I have the Watch Over Me App installed, it will redirect me to the app. If I do not have the app installed, it will redirect me to the iTunes App store to download. It is working great!
Case B: I share the app link using status update only. (without via Watch Over Me)
Result B: It will only open the blank webpage.
So, the Applink only works when we post the applink via Facebook? And not posting the Applink via our status update?
Update #2
I have tested again on 1 September 2014. Both cases above have been working well! A big Thanks Ming Li.
For everyone else who doesn't work at Facebook and understand what they mean by "indicating that your app is mobile only" here is what I have found from testing:
It appears they are using the "al:web:should_fallback" meta property as a check for if your app is "mobile only" and has no web presence. This doesn't make sense as far as I can tell based on how the App Links spec defines it but what do I know.
Anyway, if you want your Facebook post to go straight to the deep link in your app and not open up the jarring webview with random app link UX treatments by Facebook then add the following meta property to your html page:
<meta property="al:web:should_fallback" content="false" />
Of course this now prevents you from sending users without the app installed to anything but the app store. However, since the webview is usually just a repeat of the Facebook post in the first place that's probably a worthwhile tradeoff.
Since you have not indicated that your app is mobile only, it would follow the "No" arrow from the original decision box, and show your webpage along with some call to actions for either open or install.
Facebook is always testing different UX treatments, so what you see may not be what other people see. I tried posting a status update with your url, and everything is working as expected.
I'm using the jquerymobile platform with one of my Drupal sites. It works flawlessly on my dev server, but on the live server, every time I click on a link it sticks a pound sign in and refuses to load the content of the page being linked. When I hit the browser's refresh button, the pound sign goes away, and the content does load.
Example:
Sponsors
should go to http://mysite.com/sponsors. What happens on my live site is http://mysite.com/#/sponsors. The page stalls there, but if I click reload, the # goes away and the content loads.
I have a user agent switcher in firefox, so I turned firebug on, and on the live site, I'm getting the following error every time I click a link:
"attempt to run compile-and-go script on a cleared scope"
This does not occur on the dev site. The live site is http://m.shoppersummit.com/. Any ideas why this would happen? As far as I can tell, I have the same version of jquery, jqueryui, and jquerymobile installed.
Edited to address redirect loop
I've been at work since 6:30 AM; my brain is fried. This is a drupal site, with a "real" theme and a mobile theme. The only way to view the mobile theme (which is where the error is occurring) in a desktop browser is to change your user agent string to a mobile one. There's a firefox addon that will do this. If you try to view the site with a standard desktop user agent string, you will get the redirect.
Have you tried including a target? e.g. target="_self"
I'm trying my hand at building an HTML5 driven offline app for my iPad 2 which has iOS 4.3.4. I followed instructions I've seen on several websites to a tee, and was even able to verify using Chrome's Developer Tools that the cache is working:
Creating Application Cache with manifest http://localhost/experiments/test.manifest
Application Cache Checking event
Application Cache Downloading event
Application Cache Progress event (0 of 2) http://localhost/experiments/offlineApp.js
Application Cache Progress event (1 of 2) http://localhost/experiments/offlineApp.css
Application Cache Progress event (2 of 2)
Application Cache Cached event
I have a home screen icon as well as a "startup screen" image in play. I can download the app to the home screen just fine, and I see the icon there. However, when I have the Wi-Fi off and I try to open the app I get the dreaded " could not be opened because it is not connected to the Internet" alert.
Does anyone know if something changed in iOS 4.3.4 (or an earlier version of the OS) that changed the requirements to get this feature of HTML5 working?
Thanks!
Edit
I tried this again outside of a "localhost" setting. This is my HTML:
<!DOCTYPE html>
<html lang="en" manifest="/experiments/cache.manifest">
<head>
<meta charset="utf-8"/>
<title>cache.manifest test</title>
<link rel="stylesheet" href="cache-manifest-test.css"/>
<link rel="apple-touch-icon" href="icon.png"/>
</head>
<body>
<h1>cache.manifest</h1>
<p>Let's see if this thing works...</p>
<script src="cache-manifest-test.js"></script>
</body>
</html>
And this is my cache.manifest file's contents:
CACHE MANIFEST
cache-manifest-test.css
cache-manifest-test.js
I see the proper results in Chrome's developer tools. I get the "Application Cache Cached event." It just doesn't work offline. I'm really stumped here...
Does anyone know of any pages that have full blown code I could just copy to my server and try?
Thanks...
The messages you posted from Chrome are when the page is served from localhost.
Check that it works on Chrome using the server rather than localhost.
If it doesn't, check that you are serving the correct type (text/cache-manifest) for an appcache on the server.
If you're serving the correct type on localhost but not on the server, that would explain the different behavior.
Also, I've read that the file must be named "cache.manifest" on the iPad. If you have named it something else, try that.