On Fri, Jul 19, 2013 at 6:58 PM, 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.
The point here is that we start with a state machine that allows for
quite flexible policies in the long run and enables us to establish
policies on the phone that result in maximum power saving. From my
perspective, users will not blame apps for bad battery lifetime but
the system/platform. For that, a clean albeit strict lifecycle model
to get started is easier to maintain and extend than starting over
with ultimate freedom and selectively taking that away from
developers. As you said: Every form-factor requires specific lifecycle
policies. But as long as the underlying state machine/model is
consistent and clean, future iterations of those policies is not an
issue.
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.
See my comment on adjusting the lifecycle policy for different form factors.
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.
Well, we sigstop apps in the background on the phone and on the tablet
right now :) It thus cannot be that bad. However, sigkill'ing apps is
important, too, as it frees up RAM and GPU resources. To make this as
transparent to the user and the developer alike, apps are informed
that they are about to be killed/stopped and provided with an archive
to serialize their state (_not_ writing their memory image) such that
a subsequent startup gives the user the impression that the app never
disappeared. Obviously, this is something that should be as
transparent as possible to users, too and we will integrate it with
Qt/QML as seamlessly as possible. The common basis is the platform API
and higher-level SDKs will only leverage what is available from that
API. That being said, other toolkits or game engines can easily adopt
this platform functionality and provide as seamless an experience as
our QT/QML SDK.
Thomas
