3 ms·

Chrome for Android had the same buried "add to homescreen" thing for a long time: https://developer.chrome.com/multidevice/android/installtohomescreen https://d

Chrome for Android had the same buried "add to homescreen" thing for a long time: https://developer.chrome.com/multidevice/android/installtohomescreen https://developer.chrome.com/multidevice/android/installtoho... Chrome for Windows has had "Create Application Shortcut" for roughly forever: https://support.google.com/chrome/answer/95710?hl=en https://support.google.com/chrome/answer/95710?hl=en Neither indicated that a site would work well in that mode. That's a big part of the change: detection that a site meets the quality criteria + prompting.

untog 11y ago
Oh absolutely. I think this is a huge step forward - I'm mostly just moaning at a lack of cross-platform compatibility in a situation where it would be a huge deal. What was the rationale for not having a document.addToHomescreen() function? I can see it being open to abuse, but not any more or less than pop-up windows (especially when limited to only being called within touch events and so on)
- slightlyoff 11y ago
  The abuse considerations were what led us to implement the engagement check. An API for this would absolutely be spammy. If everyone is going to be calling it on every page-load, and if the browser is (predictably) not going to allow that to show every time (see window.open()), then why provide an API when we could just treat meeting the criteria we'd look for anyway as the same thing as calling such an API? That's what the Chrome system does: you've implicitly called "addToHomescreen()" on every page load where your app meets the criteria. When we allow it to show is still mediated by the browser. Chrome 44 is going to allow a measure of control: http://updates.html5rocks.com/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android#cancel http://updates.html5rocks.com/2015/03/increasing-engagement-... The event is cancelable, meaning that if you don't want it to show on a particular page, it'll trigger again on the next. We'll also be adding a way for you to delay the load; cancel and re-trigger inside the same page. The way to think about it is that you sometimes get a golden ticket. We'll give you the ability to spend it when you want in the near future, but making you do an API call when the intent is already clear just seemed like bad design.

untog 11y ago

Oh absolutely. I think this is a huge step forward - I'm mostly just moaning at a lack of cross-platform compatibility in a situation where it would be a huge deal. What was the rationale for not having a document.addToHomescreen() function? I can see it being open to abuse, but not any more or less than pop-up windows (especially when limited to only being called within touch events and so on)

slightlyoff 11y ago
The abuse considerations were what led us to implement the engagement check. An API for this would absolutely be spammy. If everyone is going to be calling it on every page-load, and if the browser is (predictably) not going to allow that to show every time (see window.open()), then why provide an API when we could just treat meeting the criteria we'd look for anyway as the same thing as calling such an API? That's what the Chrome system does: you've implicitly called "addToHomescreen()" on every page load where your app meets the criteria. When we allow it to show is still mediated by the browser. Chrome 44 is going to allow a measure of control: http://updates.html5rocks.com/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android#cancel http://updates.html5rocks.com/2015/03/increasing-engagement-... The event is cancelable, meaning that if you don't want it to show on a particular page, it'll trigger again on the next. We'll also be adding a way for you to delay the load; cancel and re-trigger inside the same page. The way to think about it is that you sometimes get a golden ticket. We'll give you the ability to spend it when you want in the near future, but making you do an API call when the intent is already clear just seemed like bad design.