ubuntu-phone team mailing list archive

[Marek Greško <mgresko8@xxxxxxxxx>]

I also vote for ability to enable cpu usage for background apps.
Application developers should always develop in enabled mode I think, apps
working in enabled mode should work also in dsabled mode. If anybody still
consider it the worst case, then I vote for enabling cpu usage for
background apps permanently and make option of cpu percentage limit for
that apps in some range. For example from 1 to 10 %.

Marek


2015-10-03 2:17 GMT+02:00 John Johansen <john.johansen@xxxxxxxxxxxxx>:

> On 10/02/2015 04:29 PM, Mitchell Reese wrote:
> > When it's a matter of principles, it can be hard to let go of certain
> ideas. Yet at the end of the day, this comes down to how well does Ubuntu
> as a phone platform compete with Android and IOS. When mobile phones first
> came into fashion (remember the 90's folks?), battery life on handsets was
> upwards of a week. I remember laughing at the first 'smart' phones, and
> their battery life of a couple days (if you were lucky).
> >
> > Then smart-phones got more powerful, and users wanted more. 1 day of
> battery life became the 'norm'. People no longer minded charging their
> device each day, providing their 'apps' worked as they should - instant
> notification, multi-tasking, working in the background. Even IOS eventually
> capitulated - I still remember back when doughnut was a thing on Android,
> how Apple maintained their phones weren't powerful enough for
> multi-tasking, when the HTC Magic (remember /that/ handset?) was able to
> manage just fine with lower specs. It was a design decision Apple made for
> - wait for it - battery life.
> >
> > Perhaps if Apple and Google had started implementing more background
> services apps could plug into, a better format could have been found. But
> that didn't happen. In the race to market, the easiest way for developers
> to engage with their devices won out. This might not have been the best
> way, but its what currently is expected in the market.
> >
> > 'Bucking the trend' is important - it can even bring great success. But
> to do so faces an uphill battle all the way. Something needs to be offered
> that's a better result than the status quo. Uber, Flow Hives, Ebay - recent
> history is full of inspired examples. This - at a minimum - needs to meet
> what's currently on offer, or throw the model away and start something
> better. Success for Ubuntu on phones will come from consumer adoption -
> consumers that are used to their apps just 'working'. People that won't
> understand - nor care - why they can't check emails while jogging. Why they
> need to keep an app 'in focus' in order for basic functionality to work.
> Why their Facebook app is only the web interface with a fancy bottom
> navigation button - why there's no messenger. Why developers don't port
> more of their apps - the fact that many developers won't be interested in
> working around Ubuntu's platform restrictions won't register with consumers
> - the fact the app isn't there will be
> > enough.
> >
> > As an end-user and consumer, technical descriptions of multi-tasking are
> next to useless. If an app won't work unless it's in the foreground, it's
> not multi-tasking. As a tech-enthusiast that uses Ubuntu in everything I
> do, I'm willing to find work-arounds. Most people won't do that. So the
> question becomes who Ubuntu is targeting? Everyday consumers who expect
> apps to work in the background (thus allowing the user to multi-task in
> their day), or enthusiasts who are willing to embrace a rougher experience?
> >
> > If battery life has ceased to become the biggest selling point in the
> market, why is Ubuntu pushing this as the most important issue? Why is ease
> of use and usability being sacrificed for battery life? Is this a matter of
> principles, or is there an overarching design decision that will push
> Ubuntu as a platform ahead of the rest? There are lots of examples on this
> mailing list of better solutions - at the end of the day, what's a better
> experience for consumers? Rather than expend so much effort working around
> the principles for Ubuntu's current app restrictions, wouldn't a better way
> forward be to optimize the system processes for battery-life, then have an
> easily accessible menu where end-users can see which app is draining their
> battery? This could then become the first port of call for users
> complaining about battery life. Apps in the store would reflect this in
> ratings - would you rate an app highly that drains your battery?
> >
> > And so a last question - rather than spending so much time and effort
> writing background processes to make apps on Ubuntu appear that they are
> working as expected on other systems, wouldn't an easier way be to remove
> the current app restrictions with regards to background processes, and
> implement a solution where users are able to see which app is draining
> their battery?
> >
>
> The app lifecycle is not just about battery life. It is all about managing
> constrained resources, of which battery life is just one, to give the user
> a good experience. Its the user experience that is what is important, that
> is why we should NOT trouble the average user with having to decide whether
> an application should be run in the background, nor should we burden them
> with having to keep an application in the foreground to have it work.
>
> There are multiple ways to deal with constrained resources, but in the end
> each of them comes down to better app design and coding. Developers are
> lazy, and honestly many of them may not even understand what is required to
> make an app run effectively in a constrained resource environment. Making
> the developer use a background system service is one way to force them into
> better app design for such an environment, it is by no means the only way
> but it is quite effective for dealing with several issues.
>
> Lets take a quick look at memory as a constrained resource. If a
> background app is consuming to much memory, the foreground app may not be
> able to get the resources it needs and start failing it odd ways. This is
> bad for the user so the system is now left with the choice of asking the
> background app to release some the memory it is using or kill it to free up
> memory. Killing the background app will free up the needed resources, but
> without some way for that task to save its state it will make for a
> terrible user experience if the user ever switches back to the task. So
> part of the design for apps that are to be run in a constrained environment
> are knowing about this limitation and being able to deal with it. Part of
> dealing with it is saving state, but that is not enough for applications
> like fitness trackers that need to keep running in the background to do
> their job. You could just tag an application as needing to be long lived
> and hope it doesn't consume too many resources or you f
> orce developers to design their apps to consume less resources in the
> background. Basically the dev needs to split their application into a
> background task and a foreground task. The background task needs to live
> within certain constraints and can continue running if the foreground task
> is killed etc. One way of achieving such a split is using system service
> daemons, another more generic method is setting up service tasks like
> modern android allows for (
> http://developer.android.com/guide/components/services.html).
>
> The end goal is the user having a good experience, whether single or
> multi-tasking. The current situation is admittedly very restricted, things
> will improve, it may take some time but all the piece will fall into place.
> They will have to, to support apps in the converged device environment.
>
>
>
> --
> 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
>