Allow direct linking to a Preview via uri

[Brian Douglass]

I can already link to a scopes search via the scope:// protocol but it would be great to be able to link directly to a preview page via a scope:// uri. This would be especially helpful for uApp Explorer to link directly to an app in the official store (rather than the search page like it does now).

[Michi Henning (michihenning)]

I don't believe any change is required on the scopes API side for this. It looks like this would be purely a shell feature.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Paweł Stołowski (stolowski)]

This poses a challenge, because shell needs to pass the complete copy of the activated result with preview request. When preview is requested by the user via the UI, the shell naturally has the result in question and can pass it. But to make this work via a canned query, we would need to serialize entire result in the canned query, so that the query can be invoked from any context of the UI. While this is doable, I think it will be very fragile and hard for apps to get right (even a subtle change in preview handling internals of the scope may break canned queries created for it by external apps).

[Brian Douglass (bhdouglass)]

Just a suggestion, but what if you had an optional feature where (if enabled) the preview would fetch the single result and display it? So for example, linking directly to an app in the click store scope would first launch an api call then show the preview using the results of the call. That way each scope can implement it (or not implement it) in a way that makes the most sense to them.

I don't pretend to know anything about the internals of the scopes implementation so my suggestion could be way off base.

[Michal Predotka (mpredotka)]

As an app developer I'm looking forward to use this kind of functionality. That way I could for example give a link in my free demo app to a paid, full version app in the store.

[Paweł Stołowski (stolowski)]

@Brian: Right. That could work under the following assumptions:
- the result uri uniquely identifies a result (currently we don't really require that nor make any assumptions around that anywhere in the shell as far as I remember) in the scope which is interested in providing that functionality;
- given a result uri, the scope can produce a *single* result in response;
- that would require a new method in the scopes API ("result_for_uri", "search_by_uri" or some such) to be implemented by scope author to provide this new functionality.
- the shell would need to do 2 calls (get the result by uri first, pass it to preview).
- alternatively, implement this with a new method such as "preview_by_uri", but I think I'm leaning towards the former approach with result_for_uri as building the previews is (usually) more complex part of the scope, so requiring scope authors to think of yet another entry point for previews is probably too much.

[Paweł Stołowski (stolowski)]

Re-assigning to unity-scopes-api as a new endpoint handler (get result by uri, or get preview by uri depending on how it ends up implemented in the shell plugin) will be needed, plus an enhancement to CannedQuery.

[Paweł Stołowski (stolowski)]

Ok, after some internal discussion about this enhancement the agreed solution is to provide a new "preview_by_key" method (temporary name) which scopes can implement to support canned queries requesting previews. The argument of this method will be a string that acts as a unique key and it's up to the scope what it really is (it can be just a uri).

[Brian Douglass (bhdouglass)]

Wonderful, I can't wait! Thank you so much for getting to this.

[Brian Douglass (bhdouglass)]

Hi guys! I was just wondering if this issue was on a feature roadmap or anything. It would be really useful for uApp Explorer.

[Paweł Stołowski (stolowski)]

Hi Brian, I started working on the implementation in unity-scopes-shell at the time we discussed this, but it turned out to be more complex than expected.

First off, the solution with preview_by_key I suggested above turned out to be a no-go, because it was incompatible with how preview actions work (I should have noticed it early...); so, the way to go is a "result_for_key" method that needs to be implemented by scopes which want to support canned queries requesting a preview.

Second off, I've some of that "new approach" implemented in the shell plugin, but we will need changes in plugin<->shell interface too, and for the unity8 shell side of things I need somebody from unity8 team. I hope this will happen at some point, but this enhancement is not a priority at the moment.

[Brian Douglass (bhdouglass)]

Thanks for the update! Out of curiosity, what sort of changes need to happen in unity8?