On Thu, Jul 18, 2013 at 8:36 PM, Rasmus Eneman <ras...@eneman.eu> 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.v...@canonical.com> >> >> On Thu, Jul 18, 2013 at 8:08 PM, Josh Leverette <coder...@gmail.com> >> 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" <ras...@eneman.eu> 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 <ja...@canonical.com> >> >> >> >> 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@lists.launchpad.net >> >> 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@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~ubuntu-phone >> > More help : https://help.launchpad.net/ListHelp >> > >> > >> > -- >> > Mailing list: https://launchpad.net/~ubuntu-phone >> > Post to : ubuntu-phone@lists.launchpad.net >> > 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
