ubuntu-phone team mailing list archive

[brandon@xxxxxxxxxxxxxxxxxxx]

Rasmus, yes.
I was very put off by Ubuntu Touch suspending (eg: commands running in the Terminal app) every time the device locked.

For 8 years now with their Maemo sdk Nokia provided to developers an easy pathway to battery-friendly media/dsp services, alarms/rtc, cell/gps location services, etc. but outside of OOM killer and watchdogs for their own daemons placed no restrictions on running programs.
More of a carrot approach than stick.

UI/daemon sounds promising to offer a similar experience to Android, but I hear alot of second-hand complaints about iOS or Android agressivly purging stock-browsers from RAM when multitasking away from more than 1 or 2 tabs.

..and also sounds like a large distance to cover to make background services more appealing to devs than an API

- bjv
(attempting to replace Nokia N900 with Ubuntu Touch on Galaxy Nexus; background media player + the gps in the browser since images 99 have been a big help.. Go team!)  

On Tue Oct 22 13:45:44 2013 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