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

[Web Install] Similarities between getInstalledApps() and getInstalledRelatedApps() #804

Open
amandabaker opened this issue Apr 29, 2024 · 4 comments
Assignees
Labels
Web Install API Declarative install for web apps from a web app.

Comments

@amandabaker
Copy link
Member

Copied from https://docs.google.com/document/d/12nSXJLm8mW0gWZ_yjlXfrV8r9gwJliVt4WVa-209-KA/edit?disco=AAABMhvdaw0

[https://developer.mozilla.org/en-US/docs/Web/API/Navigator/getInstalledRelatedApps](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/getInstalledRelatedApps%5d(https:/www.google.com/url?q=https://developer.mozilla.org/en-US/docs/Web/API/Navigator/getInstalledRelatedApps&sa=D&source=docs&ust=1714410367450615&usg=AOvVaw0K87k_bi3F1p0ywGw1gXjK)) -- it roughly does the same thing as this and it would be a shame to ship two APIs so similar (and with such similar names).

Although the new method navigator.getInstalledApps() intended for use with the Web Install API is different in function from navigator.getInstalledRelatedApps(), the name similarity could be confusing for developers. Should the API be renamed or combined with the existing getInstalledRelatedApps()?

Note the difference in intended functionality:

  • getInstalledApps(): returns a list of the apps installed from this origin via the Web Install API
  • getInstalledRelatedApps(): returns a list of installed apps on the device that are related to the current origin (as defined by "related_applications" in the manifest)
@amandabaker amandabaker added the Web Install API Declarative install for web apps from a web app. label Apr 29, 2024
@tomayac
Copy link
Contributor

tomayac commented Apr 30, 2024

Maybe rename to getInstalledAppsForOrigin()? Albeit this might lead developers to think there could be a parameter origin, which isn't the case.

@diekus
Copy link
Member

diekus commented Apr 30, 2024

I don't think getInstalledApps should be combined with getInstalledRelatedApps. The use cases are quite different and trying to reuse or expand the API could create more confusion.

I think if anything we could look at renaming the API as it has crossed my mind that the name is too similar to gIRA. @tomayac 's proposal doesn't sound bad, maybe adding "current" in there somewhere? getInstalledAppsForCurrentOrigin. The issue is it starts getting very lengthy? WDYT?

@diekus
Copy link
Member

diekus commented Apr 30, 2024

Alternatively, thinking something like navigator.getInstalledApps('related') and navigator.getInstalledApps('currentOrigin')? But I do think this would create more confusion in the end and would mean deprecating getInstalledRelatedApps(). Open to suggestions

@mgiuca
Copy link

mgiuca commented May 1, 2024

(I filed the original comment.)

Now I get it - "returns a list of the apps installed from this origin via the Web Install API" - I didn't understand that it was about the apps this origin has installed as opposed to the installation state of the apps on this origin.

I think the proposals above like "for origin" or "current origin" make that confusion even more likely: "current origin" strongly suggests it will only return the list of apps that live on the current origin, whereas it seems that this is going to return a list of apps from many different origins, that were installed by this origin.

So we're bikeshedding, but I would want a name that includes the word "by", such as "getAppsInstalledByThisOrigin". It is hard to come up with a succinct name that is specific enough to convey that it's the apps installed by this origin, not the apps that live on this origin.

Discussion of an approach to merge with getInstalledRelatedApps

This section follows a line of thinking "how would you combine this concept with gIRA?". It isn't necessarily an approach you need to take, but it should be considered and listed as an alternative, so hopefully even if you don't take this approach, you'll incorporate this thinking into your documentation.

The fact that we're struggling to come up with a name to distinguish this feature from "getInstalledRelatedApps" suggests that they are essentially the same concept. Fundamentally, it's about getting a list of installed apps (matching some criteria); the criteria of what counts as an installed app changes between the two use cases, but otherwise it's the same idea. It feels bad to me having two different APIs (with two different return types - gIRA returns a list of dictionaries whilst gIA is proposed to return a list of app IDs) that do the same thing but with a different filter.

One way forward would be to consider gIRA as "deprecated" and come up with a new API that covers both use cases. But I also think that gIRA is not too broken and could be adopted for this use case.

From gIRA's perspective, we currently consider "related apps" to be "apps you have explicitly listed in your manifest, and which link back to you" (and for PWAs, only apps that live on this origin). You could extend that definition to include "apps installed by this origin", so now gIRA by default would return both "apps installed by this origin" and "apps belonging to this origin". Then you could have a filter like what @diekus suggests, to show only "apps installed by this origin" and "apps belonging to this origin". This would also mean returning the same data structure as getInstalledRelatedApps, a list of dictionaries containing id, platform (for the new use case, always "webapp"), url, etc.

This approach could take a bit more work and care, but it feels neater to fit the new use case into the existing concept, rather than making a new method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Web Install API Declarative install for web apps from a web app.
Projects
None yet
Development

No branches or pull requests

4 participants