2

In Apple's documentation for Background Execution it is explained that 'Any app that supports the background processing of Bluetooth data must be session-based. ... Apps must provide an interface that allows the user to start and stop the delivery of Bluetooth events. That interface should then open or close the session as appropriate.'

Our iOS application acts as a CBPeripheralManager in communication with a CBCentralManager on OS X. We have problems preventing the app from becoming suspended and becoming unresponsive to communications from the Central Manager.

We are declaring UIBackgroundModes key with the bluetooth-peripheral value in the app’s Info.plist file, which should get iOS to allow us to operate in background with reduced limitations. While in background our app processes communications from the central and replies as expected for many hours, but eventually gets suspended.

The documentation implies we should be managing a session, perhaps in the way that NSURLSession manages a session, but there is no such thing as NSSession, nor CBSession, and I can find no other mention of Session in releationship to Core Bluetooth in the documentation.

Any ideas?

Phill Apley
  • 923
  • 10
  • 16
  • No, there is no explicit methods to define a Bluetooth session. In your case your session is implied by the availability/unavailability of the Bluetooth peripheral you are publishing. This is described in the [Core Bluetooth Programming Guide](https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW1). It may be that you exhausting the background execution time limit for your app – Paulw11 Dec 11 '17 at 19:45
  • My understanding is that as long as we use UIBackgroundModes 'correctly' there is no specific background execution time limit. Though perhaps for every bluetooth or network socket wakeup we must return from the callback and somehow allow the app to become 'eligible for suspension' frequently to avoid using too many cycles. Other than avoiding launching other processes that loop during processing of the bluetooth code, I'm not sure what that would entail. My understanding is that we don't need to call beginBackgroundTaskWithExpirationHandler when in this regime. – Phill Apley Dec 11 '17 at 20:32

1 Answers1

1

I am also developing a similar App but our App is in Central mode

If you read this guide Core Bluetooth Background Processing for iOS Apps

specially the section "State Preservation and Restoration"

you will see that it says

Core Bluetooth supports state preservation and restoration for apps that implement the central role, peripheral role, or both. When your app implements the central role and adds support for state preservation and restoration, the system saves the state of your central manager object when the system is about to terminate your app to free up memory (if your app has multiple central managers, you can choose which ones you want the system to keep track of). In particular, for a given CBCentralManager object, the system keeps track of:

Apps that implement the peripheral role can likewise take advantage of state preservation and restoration. For CBPeripheralManager objects, the system keeps track of:

  1. The data the peripheral manager was advertising

  2. The services and characteristics the peripheral manager published to the device’s database

  3. The centrals that were subscribed to your characteristics’ values

You can also read how to Add Support for State Preservation and Restoration on the same page below

hope this helps you

Neo
  • 1,359
  • 14
  • 34
  • We're doing that. Our implementation of state preservation and restoration seems to work, at least when the app is launched fresh from springboard, where it seems to pick up the archived connections and keep going. If the app has been suspended and/or terminated and a bluetooth message wakes it up, it's less clear that it's working 100%. – Phill Apley Dec 11 '17 at 20:37
  • 1
    first you cannot control App suspension.Secondly correct me if i took it wrong.you are saying after suspension your App does not wake up on a Bluetooth message or at-least it fails sometimes in your testing? – Neo Dec 11 '17 at 20:48
  • The 'normal' progression is foreground -> background -> suspend. Various workarounds exist to avoid going from background -> suspend. For example, if the app declares UIBackgroundModes 'audio,' then when the audio session is closed the app becomes 'eligible for suspension', but until then, if the app is 'behaving itself,' it should avoid suspension. Another way to defer suspension is to call beginBackgroundTaskWithExpirationHandler, but this is a separate mechanism which as far as I can tell is superceded by UIBackgroundModes, and I believe it gives you a maximum of 3 minutes before suspend. – Phill Apley Dec 12 '17 at 00:54
  • On the other side, if you are not distributing through the app store, or if you just want it for testing, you can supposedly force the app to suspend with this private api expression: UIApplication *app = [UIApplication sharedApplication]; [app performSelector:@selector(suspend)]; But our experiments with exactly what this does have been inconclusive. – Phill Apley Dec 12 '17 at 01:00
  • if the app declares UIBackgroundModes 'audio' and then it is not doing audio related work then you will have a greater chance of being rejected from the App store.This also applies to any other methods that prevent Suspension as Apple has strict policy regarding this – Neo Dec 13 '17 at 06:18