ubuntu-phone team mailing list archive

[Zisu Andrei <matzipan@xxxxxxxxx>]

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