Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need some way to de-duplicate web and native share targets #19

Open
mgiuca opened this issue Jun 7, 2017 · 4 comments
Open

Need some way to de-duplicate web and native share targets #19

mgiuca opened this issue Jun 7, 2017 · 4 comments
Assignees

Comments

@mgiuca
Copy link
Collaborator

mgiuca commented Jun 7, 2017

If you have both a web app and a native app (on a certain platform), you may want to prevent your web app from showing up as a share target if the user has your native app installed. Otherwise, your app may show up twice in the share picker and be confusing for the user (as it would look identical or near-identical).

This is the exact same problem (with Notifications) that prompted the development of the navigator.getInstalledRelatedApps API, so you could programmatically check and disable notifications. However, you can't directly use that with Web Share Target as we've specified it, because it's declarative.

Here's a brain-dump of some solutions:

  • Provide a programmatic API to register/unregister share targets. You could then use getInstalledRelatedApps in combination with that API to disable your share target if the native app is installed.
  • Add a new declarative manifest key share_target.disable_if_app_installed whose value is a list of RelatedApplications. Automatically do not show the share target if any of those apps are installed. Or find some way to point to an existing member of related_applications.
  • (Simplest but least customizable): If prefer_related_applications is present, do not show a web share target if any related application is installed.
@mgiuca mgiuca self-assigned this Jun 7, 2017
@mgiuca
Copy link
Collaborator Author

mgiuca commented Jun 7, 2017

@owencm

@benfredwells
Copy link

I prefer the middle approach. it is like the last approach but doesn't tie install prompting together with share.

It makes me wonder if maybe the notifications API should be extended somehow instead of adding the getInstalledRelatedApps API. E.g. when requesting notifications having a flag only_if_no_app_installed.

@mgiuca
Copy link
Collaborator Author

mgiuca commented Jun 7, 2017

Ah, there's a middle approach in between 2 and 3, which is to have share_target.disable_if_related_app_installed (Boolean), and it disables if any related app, rather than pointing at a specific one. I'd prefer that over 2, is that what you're getting at?

It makes me wonder if maybe the notifications API should be extended somehow instead of adding the getInstalledRelatedApps API. E.g. when requesting notifications having a flag only_if_no_app_installed.

Yeah I kind of thought of this too. It would certainly restrict the set of use cases for getInstalledRelatedApps to precisely what we specify, but since we've not got many good use cases for it anyway, maybe that's a good thing??? (The other use case is to restrict install prompts if your native app is already installed: is that already the behaviour of prefer_related_applications?)

I see... so if we tabulate there are really four decisions you might make based on related applications:

  • Whether to show the install prompt for the web app or the native app (that's prefer_related_applications).
  • If prefer_related_applications is false, whether to show the install prompt for the web app if the native app is already installed.
  • Whether to show web notifications if your native app is installed.
  • Whether to show a web share target if your native app is installed.

Those last three are the domain of getInstalledRelatedApps; they seem intrinsically linked in that they are about disabling web functionality that duplicates native app functionality, when the native app is already installed. It doesn't make sense to tie those to prefer_related_applications, I agree, but maybe they should all share a common flag rather than having individual ones? Should we transfer this discussion to the Manifest or getInstalledRelatedApps issue trackers?

@benfredwells
Copy link

Yep ... that's actually what I thought 2 was :)

Hmmmmm ... as discussed there seem like three approaches:

  • just use prefer_related_applications to gate everything
  • use getInstalledRelatedApps to gate everything (which will need something imperative for everything)
  • have some way for each API to specify that native shoudl be preferred if present. As discussed this might mean making prefer_related_applications a tristate, or two booleans, or something.

The third way feels cleanest for some reason, but the second feels like the most flexible. I don't feel strongly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants