ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Thu, Jul 18, 2013 at 8:36 PM, Rasmus Eneman <Rasmus@xxxxxxxxx> wrote:
>>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.
>

Sure and in the works, with a focus on:

  * Setting up alarms
  * Playing music in the background
  * Downloads

Obviously all of them live in different services. I will come back
with the respective BPs.

Thomas

>
> 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