ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 14-06-25 03:29 PM, Rodney Dawes wrote:
> 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.

That's not how bluetooth devices work on iOS. If your app is in the foreground,
you can get realtime events. If your app goes to the background and gets
suspended after a couple of minutes, your BT device needs to accumulate data and
send it periodically at which point iOS will start up your application in the
background for a maximum of a few seconds just long enough to receive and
process it.

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

No, but they need to use the services provided by iOS, they can't just run in
the background. This is what we want to do also.

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

Perhaps you should tell the developers of all the iOS IRC apps how to make their
application run in the background:

http://colloquy.info/project/wiki/MobileFAQs#CanIrunMobileColloquyinthebackground

http://www.macworld.com/article/1153252/linkinus_irc_iphone.html

http://www.appannie.com/apps/ios/app/limechat-irc-client/

Marc,