ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #03107
Re: Applications spawning other Applications
>In that model, only the foreground
>is guaranteed to run and our application mgmt is allowed to kill/stop
>background apps at any point in time
What about music applications?
With this life cycle (which is good, it's like Android activity which works
well)
you need to also have something similar to Androids services.
2013/7/18 Thomas Voß <thomas.voss@xxxxxxxxxxxxx>
> On Thu, Jul 18, 2013 at 8:08 PM, Josh Leverette <coder543@xxxxxxxxx>
> wrote:
> > I agree. A pluggable architecture (like Android's Intents) would be
> better
> > than hard coding.
> >
>
> Obviously we don't want to hardcode, but Intent's if run out of
> process do impose problems to the very strict lifecycle model we are
> going to implement for version 1. In that model, only the foreground
> is guaranteed to run and our application mgmt is allowed to kill/stop
> background apps at any point in time. While circumventing that
> restriction is certainly possible with numerous exceptions granted to
> two apps sharing an Intent, we would end up with littering our
> well-defined lifecycle model. Alternatively, intents could be modelled
> with an in-process plugin approach, but that would have security
> implications (Mark, Jamie, please correct me if I'm wrong).
>
> From my pov, giving apps the ability to refer to intents/functionality
> with a URL is pluggable and nicely integrates with our lifecycle model
> by not making any assumptions about another app's lifetime.
>
> Thomas
>
> > Sincerely,
> > Josh
> >
> > On Jul 18, 2013 12:09 PM, "Rasmus Eneman" <Rasmus@xxxxxxxxx> wrote:
> >
> > I really like a MIME type only approach for this because that makes apps
> > pluggable. If you for example have an app called barcode scanner for
> > scanning
> > barcodes and a shopping app called price checker that can use barcode
> > scanner
> > to scan barcodes to scan a products barcode and see where it's cheapest.
> >
> > Now a new app releases called qr code scanner that can do the same thing
> but
> > I for one reason or another preffer this one over barcode scanner a MIME
> > type
> > approach lets me use the app I prefer if qr code scanner implements the
> same
> > API.
> > But with a app name/id/path approch I would have to use barcode scanner
> if
> > that's
> > what price checker were designed for.
> >
> > Of cource all apps needs to be able to register new MIME types. If you
> have
> > multiple
> > apps that support the same MIME type one popup should appear letting you
> > choose
> > which one to use.
> >
> >
> > 2013/7/18 Jamie Strandboge <jamie@xxxxxxxxxxxxx>
> >>
> >> On 07/18/2013 11:14 AM, Michał Sawicz wrote:
> >> > W dniu 18.07.2013 17:38, Marc Deslauriers pisze:
> >> >> For the browser, I imagine a URL handler will take care of it, but
> what
> >> >> about
> >> >> spawning a different application that doesn't necessarily handle URLs
> >> >> or MIME types?
> >> >
> >> > And for network access I expect some platform API instead.
> >> >
> >> > I feel like the only instance where we would indeed allow spawning
> other
> >> > apps directly would be if it's bundled in the same package - and
> handled
> >> > through upstart as usual, I'd say.
> >>
> >> Well, an app may want to spawn a browser rather than implementing a
> >> webview
> >> itself. Marc mentioned the URL handler, but I don't know how this would
> >> work.
> >> Marc, can you elaborate?
> >>
> >> But for the other cases consider the MyApp click package that ships two
> >> desktop
> >> files for myapp and myapp-settings. Upstart works fine for launching
> >> either of
> >> these from the Dash. However, if myapp wants to launch myapp-settings
> from
> >> within itself, we need to define how that is supposed to happen (the
> >> specific
> >> problems are in another mailing list[1]). It can't just use:
> >> start application APP_ID=myapp-settings
> >>
> >> because we don't have a way to prevent it from doing:
> >> start application APP_ID=some-other-app
> >>
> >> There are some things we can do with AppArmor, but they don't include
> the
> >> executed app being managed by upstart.
> >>
> >> [1]https://lists.launchpad.net/ubuntu-appstore-developers/msg00296.html
> >> --
> >> Jamie Strandboge http://www.ubuntu.com/
> >>
> >>
> >> --
> >> Mailing list: https://launchpad.net/~ubuntu-phone
> >> Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~ubuntu-phone
> >> More help : https://help.launchpad.net/ListHelp
> >>
> >
> >
> >
> > --
> > Rasmus Eneman
> >
> > --
> > Mailing list: https://launchpad.net/~ubuntu-phone
> > Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~ubuntu-phone
> > More help : https://help.launchpad.net/ListHelp
> >
> >
> > --
> > Mailing list: https://launchpad.net/~ubuntu-phone
> > Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~ubuntu-phone
> > More help : https://help.launchpad.net/ListHelp
> >
>
--
Rasmus Eneman
Follow ups
References