ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Wed, 2014-06-25 at 15:39 -0400, Marc Deslauriers wrote:
> 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.

It is how bluetooth devices work in iOS, according to the docs. The
system wakes the app when a backgrounded app needs to process data from
the bluetooth device. It does not require any special buffering to be
implemented in the device.

See
https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW6


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

The services in iOS are generic framework services. There is no OBD-II
service for example. There is simply the core bluetooth service, and it
handles the waking of the app and passing the data to it. The support
for background processing is clearly documented in the iOS App
Programming Guide. It does not require implementing a new type of
service to handle new types of data over USB or Bluetooth. The
statements from this and other threads implies though, that one would
have to implement new system services for such things, on Ubuntu.

If however, we implement something in the same way that iOS implements,
I am fine with that. I don't need a separate process to do background
processing. I just need the app to be waked and handed the data when it
is appropriate to do so, without me having to get a new system service
written and shipped on the image, in order to do what I need.

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

I don't know what those apps are doing exactly for creating a
connection, but prior to iOS 7 at least, I don't think "IRC" fit into
any of the acceptable long-running background tasks allowances. As of
iOS 7, it seems to fit under the "Fetching small amounts of content
regularly" as documented in the iOS App Programming Guide. To quote the
guide:

Fetching Small Amounts of Content Regularly
In iOS 7 and later, an app that retrieves content regularly from the
network can ask the system for background execution time to check for
new content. You enable support for background fetches from the
Background modes section of the Capabilities tab in your Xcode project.
(You can also enable this support by including the UIBackgroundModes key
with the fetch value in your app’s Info.plist file.) At appropriate
times, the system gives background execution time to the apps that
support this background mode, launching the app directly into the
background if needed. The app object calls the
application:performFetchWithCompletionHandler: method of its app
delegate to let you know when execution time is available.

When the application:performFetchWithCompletionHandler: method of your
delegate is called, use that method to check for new content and to
download that content if it is available. When your downloads are
complete, execute the provided completion handler block, passing a
result that indicates whether content was available. Executing this
block tells the system that it can move your app back to the suspended
state and evaluate its power usage. Apps that download small amounts of
content quickly and accurately reflect when they had content to download
are more likely to receive execution time in the future than apps that
take longer to download their content.

When downloading any content, it is recommended that you use the
NSURLSession class to initiate and manage your downloads. For
information about how to use this class to manage upload and download
tasks, see URL Loading System Programming Guide. 


So, those IRC clients will need to implement this per that
documentation.