ubuntu-phone team mailing list archive

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