ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Thu, 2014-03-06 at 13:02 -0300, Alejandro J. Cura wrote:

> On Mon, Mar 3, 2014 at 11:38 AM, Ted Gould <ted@xxxxxxxxxx> wrote:
> > What we're doing for alarms is having the application provide a URL that
> > gets called if the user clicks on the notification. So the clock app sets up
> > an alarm and sets the URL to "alarms:///foo/whatever" and registers for that
> > URL in the URL Dispatcher. When the user clicks on the notification the
> > Date/Time User Service then sends that URL to URL Dispatcher and closes the
> > notification. URL Dispatcher (and all the app startup machinery) takes care
> > of running the app and then the clock app shows the data to the user. This
> > nicely makes it so that the Date/Time User Service doesn't know much about
> > clock app and can be used for other types of alarms for other applications.
> >
> > This doesn't directly solve the problem for the Download Manager as URLs do
> > require the application to startup and be shown to the user, and for
> > instance in the click case, we'd want that to happen in the background (I
> > assume). But, I'm not sure how 3rd party applications can interact with the
> > Download Manager to get background downloading, perhaps it would work for
> > them. Then we could handle the click scope case as the special case.
> 
> Indeed, we want the installation to happen in the background.
> And for 3rd party downloads, if the app is in the background or closed
> I think we don't want it brought to the front nor restarted.
> 
> So, in both cases we need to show some kind of notification:
> - "Sample App" has been installed, click here to run it.
> - "Sample Mp3 album" has been downloaded, click here to listen.
> 
> It sounds to me that URL dispatcher is mainly for opening apps; does
> it make sense for "non-foreground operations", like installing the app
> or showing a notification?
> Or should we use a different mechanism?



The question is whether the end result is "the click is installed" or
"the user is told that it's downloaded, and then can choose to install
it." And that is a design question, where I haven't seen the design.
Clearly in the case of "mp3 downloaded" playing the MP3 is probably not
the desired result, I wouldn't want the people at the sprint knowing I
was eagerly downloading the new Katy Perry, they might make fun of
me ;-)

For the case of knowing that something has finished downloading and
starting an app to do it that'll be handled by the transfers indicator.
So that case is already handled. The question for me is if the click
download/install case is special here. Which really needs to go back to
the design question. Is there a design available for that workflow?


> I kind of like there being a registry for these kind of operations
> (like android Intents), but I'm afraid we would not be able to stop a
> rogue app from installing a random click downloaded from elsewhere,
> which might be the case for some locked down operators.


Hopefully once Qt5.2 lands we can get a silo for URL Dispatcher to
finally land the branches that allow applications to register for custom
URLs. We also allow applications to provide their own data sources/sinks
for the content hub.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part