>From the application lifecycle draft: > Application authors can implement the respective lifecycle delegate > callbacks to receive notifications about being suspended, stopped or > destroyed.
What is unclear at this point is what can an application do during that callback? How long does it take before the state-change happens? How would you measure such a thing in a native environment. we define a special application property “LongRunningBackgroundInstance” > that allows an application to express its need to be kept alive in the > background for a long time (as long as it does not waste resources). This > flag is not available to ordinary applications but can only be used by > (core) applications This should be, somehow made available for all the applications. A crazy example would be an application that when I am on wifi pings all my servers and notifies me if something goes bad. Would you be able, as an application, to run a background process? Is that what the application model is for? I saw there were some application examples there, like the bittorrent app and what not, I guess they are facing the same issue as my question. Zisu Andrei On 19 July 2013 19:13, Mike Bybee <mby...@dometrilogy.com> wrote: > On 07/19/2013 10:47 AM, Josh Leverette wrote: > > "So my specific questions were directed to how we want to manage that - > since a hard sigstop when an app switches would be equivalent to a crash to > almost every current app in the app store. Obviously, lots of apps will be > created *for* touch, but the point all along has been that it should be > trivial to migrate existing QT apps back and forth - and overly aggressive > killing of apps will hinder that." > > What? SIGSTOP pauses it. It doesn't kill it. The app is never made aware > of the fact that it was stopped. Once you send SIGCONT to it, it picks up > right where it left off. > > > On Fri, Jul 19, 2013 at 11:58 AM, Mike Bybee <mby...@dometrilogy.com>wrote: > >> On 07/19/2013 09:32 AM, Zisu Andrei wrote: >> >> "let the user decide" is one of the reasons why foss fails with inexperienced >> users, plus, you really don't want that extra level of complexity on a >> phone. >> >> The game doesn't really need to run in the background when it is >> not being played. You will just do design your game loop around that, but, >> in a server - client architecture, the update loop is on the server most of >> the time, so... No problem there. >> >> I guess the only valid argument is the one with the loading browsers. >> Modern browsers don't repaint inactive tabs anyway, but javascript still >> runs and eats cycles you'd really wanna keep. If Ubuntu's gonna have >> something for that, it's gonna be a big plus. >> >> On Friday, July 19, 2013, Mike Bybee wrote: >> >>> On 07/19/2013 09:04 AM, Thomas Voß wrote: >>> >>>> On Fri, Jul 19, 2013 at 5:51 PM, Mike Bybee <mby...@dometrilogy.com> >>>> wrote: >>>> >>>>> On 07/19/2013 08:45 AM, Josh Leverette wrote: >>>>> >>>>> The spec looks very promising. >>>>> >>>>> >>>>> On Fri, Jul 19, 2013 at 10:06 AM, Thomas Voß < >>>>> thomas.v...@canonical.com> >>>>> wrote: >>>>> >>>>>> Hey there, >>>>>> >>>>>> you might be interested in: >>>>>> >>>>>> * >>>>>> >>>>>> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-add-app-model-and-lifecycle-to-platform-api >>>>>> * and the corresponding spec in: >>>>>> >>>>>> >>>>>> https://docs.google.com/a/canonical.com/document/d/1ij8RtPsR_eYMW3mys8Gu1Y2CVFZpjXdMpdIjIGZ1SCA/edit# >>>>>> >>>>>> In summary: We will implement a very strict lifecycle policy, too, and >>>>>> one that seamlessly adapts and extends to different form-factors. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Thomas >>>>>> >>>>>> On Fri, Jul 19, 2013 at 4:46 PM, Zisu Andrei <matzi...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hey guys, >>>>>>> >>>>>>> What I find interesting in the iPad (I just have one because I need >>>>>>> it >>>>>>> for >>>>>>> work) and recently in Mac OS Mavericks is their power managent >>>>>>> policy. >>>>>>> >>>>>>> Put simply, in iOS, except a few very special cases, you applications >>>>>>> will >>>>>>> be stopped when they go into background. So the foreground app gets >>>>>>> full >>>>>>> reign of both memory and CPU. This also has a very beneficial effect >>>>>>> on >>>>>>> battery life - in Android, apps running in the background still eat >>>>>>> cputime. >>>>>>> >>>>>>> What OS X Mavericks is doing is taking this idea further into a >>>>>>> noteboook >>>>>>> environment [1] with their application nap and timer coalescing. You >>>>>>> really >>>>>>> only get the most out of your battery. >>>>>>> >>>>>>> While this might not totally work in an environment like Ubuntu, >>>>>>> would >>>>>>> it be >>>>>>> possible to throttle the foreground application and slow down the >>>>>>> background >>>>>>> ones? What would this imply? Is it do-able in the current state of >>>>>>> Ubuntu >>>>>>> Phone, or do we need extra things at kernel level? >>>>>>> >>>>>>> [1] http://www.apple.com/osx/preview/advanced-technologies.html >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Sincerely, >>>>> Josh >>>>> >>>>> >>>>> >>>>> So, using a common example of an IM client or media player - would we >>>>> assume >>>>> that would stay in "unfocused" state? You mention that only core apps >>>>> can >>>>> run as background - that would mean it's not a valid state for a >>>>> normal 3rd >>>>> party app. >>>>> >>>>> Even core apps will not be allowed to run in background. We have an >>>> exit strategy in terms of the flag described in the document, but we >>>> will most likely not use it. However, we will provide services within >>>> the system (media playback, downloads, alarms) to allow apps to >>>> describe specific background operations. We will extend the list of >>>> supported operations over time. >>>> >>>> HTH, >>>> >>>> Thomas >>>> >>>> >>>> >>> I would suggest that we want to fall closer to Android's app model than >>> Apple's - or perhaps let the user decide how heavily it policies background >>> apps. A mobile can get by with very limited background apps - but a tablet >>> will not. My android tablet frequently has multiple apps running that I >>> switch between regularly, from allowing a slow website to load while I'm >>> writing a doc to a game that I pause so I can look up a hint. >>> Let's not paint ourselves into a corner before we even start. >>> >>> -- >>> 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 >>> >> >> >> -- >> Zisu Andrei >> >> By "let the user decide" I don't mean we should confront people with >> it - I just mean it should be available for adjusting, much like swapiness >> is. Most people will never touch it, but it is nice to have. >> I think we really need to just go for the policy of "least surprise", >> right? If you want to swap between apps, they need to be able to behave as >> you'd expect them to. Especially with a tablet. >> >> I mean, what if you want to copy/paste something between your password >> keeper and an app - you wouldn't want either one to "crash" or "vanish", >> nor the clipboard to vanish. >> >> So my specific questions were directed to how we want to manage that - >> since a hard sigstop when an app switches would be equivalent to a crash to >> almost every current app in the app store. Obviously, lots of apps will be >> created *for* touch, but the point all along has been that it should be >> trivial to migrate existing QT apps back and forth - and overly aggressive >> killing of apps will hinder that. >> >> -- >> 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 >> >> > > > -- > Sincerely, > Josh > > > "What? SIGSTOP pauses it. It doesn't kill it. The app is never made aware > of the fact that it was stopped. Once you send SIGCONT to it, it picks up > right where it left off." > > Ok, so that would work great then, thanks for the clarification. My > biggest concern was just as a user (with my usage patterns), and as a dev, > writing apps that will definitely run in the "background" on occasion. >
-- 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