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

Deep linking - need proper use cases and requirements analysis #363

Closed
marcoscaceres opened this issue Apr 22, 2015 · 14 comments
Closed

Deep linking - need proper use cases and requirements analysis #363

marcoscaceres opened this issue Apr 22, 2015 · 14 comments

Comments

@marcoscaceres
Copy link
Member

In #332 (comment), @PaulKinlan said:

Also deeplinking, the section in the spec makes no sense. Is there a plan for it to be expanded? I ask because Deep linking on Android has a very specific configuration, and I would expect to see some configuration of ownership of multiple paths, protocols etc (potentialy via a scope).

We should do a proper analysis of how this stuff works on Android. What is currently in the spec may indeed be insufficient.

@benfrancis
Copy link
Member

See also #380 (comment)

@alxlu
Copy link

alxlu commented Aug 16, 2015

Has there been any updates on this?

See also #380 (comment)

If I'm understanding the comment @benfrancis made correctly, having the WebApp 'register' to handle URLs that are within its scope is how I interpreted deep linking as well. I think it's a promising way to handle deep links and definitely something to explore further.

It would be great to see if anyone has any thoughts about the potential downsides of this—particularly whether or not it conflicts with existing deeplinking solutions for native apps.

@kenchris
Copy link
Collaborator

I haven't unfortunately. @PaulKinlan, do you have anyone on your team familiar with the native deep linking who could look at this?

@alxlu as long as it is restricted to URL scopes within its own domain, I think this could work. The problem is when multiple apps register for the same scopes, but maybe that can be looked at as an enhancement in the future.

I would assume that registering for these scopes (and adding handlers) should happen in a Service Worker, as the app might not be running and because it gives a lot of flexibility.

We could then look at how to make the Service Worker launch the app in "web app state" - using the info from the manifest.

It is already possible to launch the app from the Service Worker based push notifications, but I would assume that that also just launches the app in the browser currently. @PaulKinlan can you confirm? We should really fix this.

@PaulKinlan
Copy link

I know native deep linking well. Will spend some time looming into a reply
for this thread (sorry for this empty reply)

On Mon, 17 Aug 2015 09:50 Kenneth Rohde Christiansen <
notifications@github.com> wrote:

I haven't unfortunately. @PaulKinlan https://github.com/PaulKinlan, do
you have anyone on your team familiar with the native deep linking who
could look at this?

@alxlu https://github.com/alxlu as long as it is restricted to URL
scopes within its own domain, I think this could work. The problem is when
multiple apps register for the same scopes, but maybe that can be looked at
as an enhancement in the future.

I would assume that registering for these scopes (and adding handlers)
should happen in a Service Worker, as the app might not be running and
because it gives a lot of flexibility.

We could then look at how to make the Service Worker launch the app in
"web app state" - using the info from the manifest.

It is already possible to launch the app from the Service Worker based
push notifications, but I would assume that that also just launches the app
in the browser currently. @PaulKinlan https://github.com/PaulKinlan can
you confirm? We should really fix this.


Reply to this email directly or view it on GitHub
#363 (comment).

@benfrancis
Copy link
Member

kenchris wrote:

I would assume that registering for these scopes (and adding handlers) should happen in a Service Worker, as the app might not be running and because it gives a lot of flexibility.

On Firefox OS we register the URL scope when a site is "pinned", it's completely orthogonal to Service Workers.

@alxlu
Copy link

alxlu commented Aug 21, 2015

Yes, I think it would be best to keep this independent from Service Workers for us as well.

@marcoscaceres
Copy link
Member Author

We need to check what came of Balista.

@marcoscaceres
Copy link
Member Author

@mgiuca, we should chat about Balista... I hear you are also in Australia (I'm in Melb), so that makes things a bit easier :)

@benfrancis
Copy link
Member

I had a look over Ballista (which looks great BTW), but I don't think that's the same thing as deep linking.

Deep linking is about enabling hyperlinks for installed web apps, a fundamental feature of the web. It's about users being able to follow a hyperlink to a URL which falls within the URL scope covered by the manifest, other than the start_url, and for the manifest to be applied.

We have an implementation of deep linking using W3C Web Manifests in Firefox OS 2.5 so I can help provide use cases.

An example would be:

http://foo.com/myapp/manifest.webmanifest:

{
 " name": "my app",
  "start_url": "/myapp/index.html",
  "scope": "/myapp",
  "display": "standalone"
}

http://bar.com/page.html:
<a href="http://foo.com/myapp/deep.html">deep link</a>

Clicking the hyperlink in page.html would navigate to deep.html and result in a browsing context with the manifest applied, so in this case it would have the standalone display mode.

A use case might be clicking on a link to a Facebook page from another website and that Facebook page opening in the installed Facebook web app, or following a link to a news article inside an installed news web app.

In Firefox OS we dynamically apply the manifest to the current browsing context when it is navigated to a URL within the scope of a "pinned" web app. I'm not sure what the UI for this should look like in other implementations like Chrome/Opera on Android where there is more of a distinction between app windows and browser tabs.

Ballista is different to deep linking because it doesn't use a hyperlink directly to a URL, there's a layer of indirection where it requests an "action" which could be handled by one of many web apps, of which the source app need have no knowledge. I have taken the liberty of filing a separate issue #442 for that.

@marcoscaceres
Copy link
Member Author

So yeah, my definition (and maybe the one in the spec?) of deep linking matches what @benfrancis said. I guess actions are a kind of fancier deep linking.

@mgiuca
Copy link
Collaborator

mgiuca commented Apr 1, 2016

I think I agree with @benfrancis here (though I'm not exactly sure what deep linking is in the context of a web app). Ballista (as we've been discussing it so far -- note that it is not a rigorous proposal at this stage) is all about sending a generic action with no specific target, and letting the user pick a target. Letting the requesting site send an action to a specific target could be in scope for Ballista but hasn't been on our radar so far.

@marcoscaceres I'd love to chat about Ballista. Note that at this stage we're doing experiments and thinking about the API. We aren't ready to talk standards yet.

@marcoscaceres marcoscaceres added this to the Level 2 milestone Apr 22, 2016
@cvan
Copy link
Contributor

cvan commented Jan 4, 2018

The IPFS project's WebExtension browser extensions uses a custom manifest key called protocol_handlers.

Just thought I'd add some usage in the wild of a use case for a protocol_handlers key.

@marcoscaceres
Copy link
Member Author

Should probably prefix that with “ipfs_” so it’s more clear it’s non-standard.

@marcoscaceres
Copy link
Member Author

I'm inclined to close this and hold with current definition of a "deep link" (which is platform agnostic): A deep link it a link that is within the scope of a manifest.

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

7 participants