›

Restoration identifier not set in central manager

fabiorodellafabiorodella
in iOS
I was going through the SDK code and noticed that a value for CBCentralManagerOptionRestoreIdentifierKey is not set in the CBCentralManager instance created by MBLMetaWearManager. The app we are developing depends on having a persistent connection in the background even if the app is not running, so we need to have CoreBluetooth state preservation/restoration enabled. Would it be possible to allow the SDK user to set that if required?

Comments

  • EricEric
    It's something that can be considered.  The typical use for the devices is you configure them gather data then decide if you want to stream or log the data.  If streaming, then keep the app active until you are done.  If logging, the connection and app is closed, then re-established when the user is ready to download the data.

    What is your specific use case for the devices that require persistent connections?
  • fabiorodellafabiorodella
    Hi Eric!

    Our app presents a series of tasks to the user, which can be completed manually or by interacting with a Bluetooth peripheral. The idea is that interacting with the peripheral should forward the event to the app as soon as possible so that we can provide immediate feedback through a local notification if your phone is nearby, even if the app is not currently in the foreground. We also have logic to handle "history" data in case the phone wasn't available when the interaction took place (which is already neatly supported in MetaWear using the logging feature).

    To achieve that, once a peripheral is "paired" to the app we always issue a no-timeout connection request as soon as the peripheral disconnects. Due to CoreBluetooth state preservation, this connection request is picked up by iOS if our app is closed while in the background, and the app is relaunched when the connection succeeds. At that point we download any history data and set-up indications/notifications to handle the events during the brief window while it's connected, and once it disconnects we repeat that process.

    We already have that scenario working great with other BTLE peripherals (weight scale), and ideally we would like to do the same with MetaWear. 

    If supporting state restoration is too tricky, another option I can think of is exposing the "metaWearFromPeripheral" method in MBLMetaWearManager, so that we can handle the connection process ourselves and once we have a connection we can then use the MetaWear API to interact with the peripheral. Although I'm offering this suggestion based only on a cursory exploration of the SDK code, and there might be other state handled in MBLMetaWearManager that would not allow this solution.

  • EricEric
    edited September 2017
    Ah I see, that is a useful iOS feature that the SDK could take advantage of.  Unfortunately the iOS dev is out of the office at the moment so I can't really say one way or the other; I've forwarded this thread to him for when he gets back.

    Since the SDK is freely available, you could try setting the the 'CBCentralManagerOptionRestoreIdentifierKey' field yourself in a local copy and test the change with the StarterProject.
  • stephenstephen
    Just wanted to confirm that support for this is in our development pipeline, but it is at least a couple months out.  If that timeline is too long, then your best option is modify the SDK as needed to enable your use case.
  • user295145user295145
    Can I give a little bump here. Implementing the Core Bluetooth programming guide is the first step. We also need a way to restore the current state upon waking up in background mode. The device doesn't disconnect when the app is suspended in this scenario.
  • EricEric
    As stated previously, you should fork the SDK repo and customize the code to suit your use case if you need these features soon.
  • keiwanmosaddeghkeiwanmosaddegh
    edited June 2018

    Just curious how this all went. I'm currently in the same situation and wonder how I should go about. :)

    Thank you in advance.

    @Eric said:
    As stated previously, you should fork the SDK repo and customize the code to suit your use case if you need these features soon.

  • EricEric

    @keiwanmosaddegh said:
    Just curious how this all went. I'm currently in the same situation and wonder how I should go about. :)

    Thank you in advance.

    @Eric said:
    As stated previously, you should fork the SDK repo and customize the code to suit your use case if you need these features soon.

    No updates have been made to the SDK. You will need to add this change to your own fork if you need it.

This discussion has been closed.