ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Wed, 2014-06-25 at 14:44 -0400, Marc Deslauriers wrote:
> On 14-06-25 02:11 PM, Rodney Dawes wrote:
> > On Wed, 2014-06-25 at 13:23 -0400, Marc Deslauriers wrote:
> >> So I gather you have the same problem on iOS, as much of the same limitations
> >> exist there?
> > 
> > I don't now, nor have I ever, owned any iOS devices. Nor have I
> > developed any apps for them. I do know that the types of apps I want to
> > write, do exist on iOS though, so clearly there must be some way to run
> > background services on iOS, even if it simply means that an app with
> > full UI is running in the background.
> > 
> > For example: http://www.innovatemotorsports.com/products/ot2.php
> > 
> > This app supports logging and performance metrics. Surely they don't
> > expect the user to tap the screen every 5 seconds to keep it alive,
> > while also trying to drive a car at its peak performance on a race
> > track.
> > 
> > So how is iOS enabling apps with requirements for background processing
> > like this?
> 
> AFAIK, iOS 4 allowed an app that was in the foreground to run in the background
> for a few minutes to finish processing. I think it used to be 10 minutes, and
> was reduced with iOS 7 to improve battery life.
> 
> In this case, isn't the app simply running in the foreground?

No. It means the app is running, whether it is in the foreground or
background. It doesn't need to be the current foreground app. Running
apps, the automotive data logging app I linked, etc… continue running
even in the background, to be able to monitor location, log performance
data from BT/ANT+ devices, and perform actions based on location or the
data stream from a connected device.


> > There is no designed way of displaying that information to the user
> > currently.
> 
> Hum? That is what trusted helpers do. When an app wants to access the user's
> location, there is a prompt which asks for permission. That's what the trusted
> prompt session work in Unity 8 is about.

That is not installation time. My reply was following the context. :)

>  It however, is totally possible for any information about
> > those permissions in the click package, to be indexed by the store, and
> > it would be possible for the click scope to show that information, in
> > the app details, and in a confirmation page when the user clicks
> > Install.
> 
> That is the exact thing we're trying to avoid. Users aren't able to either
> understand or make informed decision when they hit confirmation pages,
> especially during installation. The Android model is broken, let's not emulate it.

Why are they not able to understand or make informed decisions? Do we
have actual user testing and psychological analysis data for this? Or
are we just assuming that is the case because the way Android does
things lacks fine grained or meaningful descriptions of what an app
needs, and that people have just gotten used to apps having to request
access to everything, and thus ignore the meaning of what it is asking?
You know, much in the same way that users don't read license agreements
or terms of service, and just automatically click through the process to
get it over with?

I agree that the habits are bad, but bad habits do not indicate the
inability to understand or make an informed decision. It certainly does
not mean we can't work to provide meaningful information at the point of
looking through the app store, or during installation, either.

> >> I'm sorry, but AFAIK, iOS has very limited background service capabilities, and
> >> it seems to be doing just fine. That is the model we should be looking at, not
> >> the Android model.
> > 
> >> How would you write those apps for iOS?
> > 
> > https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20
> > 
> > Apps can have long-running background tasks for certain things, on iOS.
> 
> Apps can only run in the background for a limited time, and they can use certain
> APIs to get woken up regularly, but they can't run in the background save for a
> few exceptions. This is why IRC apps on iOS disconnect after a few minutes, or
> are designed for jailbroken devices.

No, apps can run in the background indefinitely, per the documentation
link I provided above, in order to handle a situation in the specific
list of situations described in that documentation. Skype does not
automatically disconnect after a few minutes. And AFAIK, it does not
need to remain in the foreground to stay on a call.

Maybe the app with full UI needs to remain open always on iOS, and there
are not actual separate background processes without UI, but they do not
need to remain in the foreground to remain processing.