ubuntu-phone team mailing list archive

[ajalkane <ajalkane@xxxxxxxxx>]

I agree with the original poster that the current lifecycle model is too
strict (if I have even understood it correctly by the various descriptions
in this mailing list).

I do understand the need to control running applications in devices running
on battery. But still, the current approach seems too much like thinking
about some use cases the designers came up with and giving some exceptions
and services that the applications can use to achieve the goal. With this
kind of approach the result is just stiffling innovation and what can be
achieved with Ubuntu phone. In the long run I fear also that adding
exceptions and services for all the different kind of use cases that come
up makes it just too much complexity to manage, or the other solution is
just not allow such use cases and making the platform inflexible.

There's no way around it that for some applications there needs to be a
service running on background that should not be suspended even if
application is closed, or another application is changed to. And there is a
need for some applications that the application can keep on running even if
it's switched to background, or screen saver goes on.

At the same time it's understandable that users should not be blindsided by
applications that have the potential to consume battery even when not used.

There's several solutions (or combinations of them), and only some that
come to my mind that I list here:
 - Application specifies that it has a background process that needs to run
all the time for correct functioning
 - Application specifies that it needs permission to run in background also
to function properly (for simple apps like metronome that a separate
background process would be overkill for developer)
 - Ubuntu touch allows applications to run how they will and let a visual
display (like red rectangle around for indication of heavy CPU usage) on
the application thumbnail and/or application reviews to take care of
informing users of possibly CPU draining applications

For the solutions that depend on applications asking permissions, I think
it is important that user is not only made known of the permissions asked,
but also be able to control whether they want to grant such permission.
This can be something that is done somewhere down the line, but the
principle is important - user being in control.

Sorry for the long post, but this issue is one that has quite much
discouraged me being interested in Ubuntu touch as a developer. For another
point, Nokia's Linux platforms N900 and N9 allowed applications to run as
they wanted without restrictions. Of course both platforms are tiny
compared to Android so their example does not guarantee success for Ubuntu
touch if it follows their path - still, I think Ubuntu can do better than
some ugly hybrid of iOS and Android model.



On Tue, Oct 22, 2013 at 9:45 PM, Rasmus Eneman <Rasmus@xxxxxxxxx> wrote:

> >I do disagree with requiring the user to interact with the system to
> >ensure longer battery life. We should try as hard as possible to make
> >this automagically work.
>
> >For a tech-savvyy audience: Yes. For everyday users I do disagree. In
> >the end, users do blame the platform for bad battery life (for a good
> >reason) and we certainly don't want to have battery life preserving
> >apps in our app store (Google Play has got quite a few of them).
> While automagically is great when it works, it's a real hassle when it
> don't.
> I agree that users will be put of if there is a lot of battery drain,
> however
> users will also be put of if they can't use their phone as they would
> expect
> (Android have become huge and more and more users learn that they can
> do things in the background on their phone too).
>
> A golden path have to be found between features and battery. Personally
> I think Android does pretty good here but I get a feeling that you don't?
>
> >my point of view is still that forcing every little small app to bring
> its own
> >daemon will:
> >
> >a) scare off people for writing apps for our platform as the communication
> >overhead between a service and the UI is a huge effort and easy to mess
> up.
> Android have AIDL (http://developer.android.com/guide/components/aidl.html
> )
> to help developers with this, I have used it and have to say that it's
> very simple
> to use. Hopefully something like this could come to Ubuntu too (it would
> make
> sense on the desktop as well).
>
> >b) be suicide in terms of battery usage. This will cause exactly the
> opposite
> >than what it should. If everyone brings its own daemon we'll have tons of
> >services running all the time and the user can't even stop them because
> there
> >is no UI to stop them.
> Again: Android.
> Android kills a service if the resources are needed, if the developer
> wants to
> create an app which have a responsible chance to stay alive even if the
> user
> does something else he have to create an ongoing notification. This makes
> to user aware that the app is running.
>
>
> 2013/10/22 Jamie Strandboge <jamie@xxxxxxxxxxxxx>
>
>> Pulling in Zoltan, Daniel and David for comment
>>
>> On 10/22/2013 05:40 AM, Thomas Voß wrote:
>> > On Tue, Oct 22, 2013 at 12:33 PM, John Lea <john.lea@xxxxxxxxxxxxx>
>> wrote:
>> >> From a design point of view, the guidance we are currently following
>> is:
>> >>
>> >> - Only the app in the foreground when the phone is unlocked is
>> guaranteed to
>> >> be running.
>> >>
>> >> - In all cases where an app requires functionality that needs to run
>> in the
>> >> background and/or while the phone is locked, this functionality will
>> need to
>> >> be split off into a separate daemon that will be packaged and ship
>> together
>> >> with the foreground UI app.  The daemon will have no UI, and it's
>> functions
>> >> will be started and stopped using the foreground UI app.
>> >>
>> >> Applying this guidance to the use cases below:
>> >>
>> >>
>> >>
>> >> On 21/10/13 23:46, Jamie Strandboge wrote:
>> >>>
>> >>>   * a metronome app for musicians to practice to (2 are in the app
>> store
>> >>> now)
>> >>
>> >>
>> >> The metronome app could be split into a UI app and daemon.  The UI app
>> would
>> >> start/stop the metronome and configure the sound/timing, and the daemon
>> >> would play the sound.  The daemon would continue playing the sound
>> >> irrespective of UI app state until the user switches the metronome off
>> via
>> >> the UI app.  This is useful in the case where a musician wants to set
>> the
>> >> metronome running, and then focus say a synthesiser app to practice on.
>> >>
>> >> Just forcing the Metronome app to run when the phone is locked and the
>> >> metronome app is in the foreground does not support this use case, the
>> 'UI
>> >> app' and 'deamon' approach seems a better fit.
>> >>
>> >>
>> >>>   * a white noise app to help people sleep (1 in the store)
>> >>
>> >>
>> >> Again I think splitting the White Noise app into a separate UI app and
>> a
>> >> daemon that plays the sound is advantageous.  This is because the user
>> might
>> >> for example also want to run a separate Sleep Pattern monitoring app
>> at the
>> >> same time.  Restricting the White Noise app to only running when it is
>> in
>> >> the foreground (irrespective of the phone lock state) precludes this
>> use
>> >> case.  btw, the Sleep Pattern monitoring app would also be broken into
>> a UI
>> >> app and a deamon.
>> >>
>> >>
>> >>>   * a navigation app that speaks the directions to you as you drive
>> (none
>> >>> in the
>> >>>     app store AFAIK, but this would be a wonderful addition)
>> >>
>> >>
>> >> I think the UI app / deamon split is a better solution for the problem
>> as
>> >> well (again because the user will sometimes want to perform other tasks
>> >> while the navigation app continues to speak directions).
>> >>
>> >>
>> >>>   * internet radio apps (there are at least 2 in the store)
>> >>
>> >>
>> >> I think the UI app / deamon split works here?
>> >>
>> >>
>> >>>   * a 3rd party alarm clock (perhaps the API that the core app clock
>> uses
>> >>> is
>> >>>     sufficient-- I haven't checked)
>> >>
>> >>
>> >> Same as above.
>> >>
>> >> It looks to me like the UI app / deamon split solves all the use cases
>> we
>> >> have currently thought of, are there any reasons why we should not
>> follow
>> >> this approach in all these cases?
>> >>
>> >
>> > Nope, I do fully agree with your examples here. And it is close to the
>> > aforementioned Activity/Service approach.
>> >
>>
>> It sounds like what we are saying is that we don't have to change
>> anything in
>> the system, we just need to communicate to developers how they should
>> program
>> within the system for these sorts of apps.
>>
>> Sounds like what is needed here is:
>>  * the SDK to treat compiled apps as first class citizens (I know this is
>>    planned, perhaps Zoltan can comment on its status)
>>  * documentation on developer.ubuntu.com that explains in developer
>> terms how
>>    power management and application lifecycle work, specifically for
>> HTML5,
>>    Cordova, pure QML and this new QML ui with background service. I did
>>    something similar for application confinement[1] which has been quite
>> helpful
>>  * provide an example QML ui with background daemon. We have a pure QML
>>    tutorial[2][3] for a currency converter. Perhaps a simple white noise
>> app
>>    that uses qtmultimedia in the backend service would be a good example
>>    (though a simple metronome might be better since the white noise app
>> could
>>    in theory use the media service). The docs[2] could call this 'QML with
>>    background service' (or something)
>>
>> If we did the above, app developers know where they stand and they can
>> get their
>> work done now while we build out various system services and SDK support
>> to
>> better support common use cases. Daniel and David, what do you think about
>> changes like this for http://developer.ubuntu.com? Does it make sense?
>>
>> [1]
>> http://developer.ubuntu.com/publish/apps/security-policy-for-click-packages/
>> [2]http://developer.ubuntu.com/apps/
>> [3]http://developer.ubuntu.com/apps/qml/tutorial/
>>
>> --
>> Jamie Strandboge                 http://www.ubuntu.com/
>>
>>
>> --
>> 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
>>
>>
>
>
> --
> Rasmus Eneman
>
> --
> 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
>
>