ubuntu-phone team mailing list archive

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

On Fri, Jul 19, 2013 at 9:41 PM, Zisu Andrei <matzipan@xxxxxxxxx> wrote:
> 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.
>

Pretty much everything the application wants, it's a grace period
granted before the state change happens. More to this, apps are not
constrained to classical Posix signal-handling semantics but are free
to call whatever they want. Grace time is measured in wall clock time,
and yes, this is obviously not accurate to the microsecond but still
accurate enough.

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

We will not make that flag available to normal applications to prevent
abuse. We might come up with a system setting that alters the
lifecycle policy in such a way that apps are neither stopped or killed
in the background but the default behavior will discourage and prevent
from background tasks and offer session/system services to escape the
lifecycle "trap" (e.g., a download service, a media playback service).

Thomas

>
> Zisu Andrei
>
>
> On 19 July 2013 19:13, Mike Bybee <mbybee@xxxxxxxxxxxxxxx> 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 <mbybee@xxxxxxxxxxxxxxx>
>> 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 <mbybee@xxxxxxxxxxxxxxx>
>>>>> 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.voss@xxxxxxxxxxxxx>
>>>>>> 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 <matzipan@xxxxxxxxx>
>>>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>> 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@xxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>