permission for background bluetooth usage

[felix-dumit]

#21 - Implemented permission for using Bluetooth Peripheral Manager in the background

[nickoneill]

Thanks @felix-dumit! I've never worked with bluetooth before but it seems this is similar to location in that you need to set a few plist values in the project to get the permission to show up.

Can you add these requirements to the readme near the location information?

[felix-dumit]

The string value with the reason in the plist is optional, but you have to enable the 'acts as Bluetooth accessory' background mode in capabilities.

I'll add that to the readme later.

—
Sent from Mailbox

On Sun, Jun 21, 2015 at 1:45 PM, nickoneill notifications@github.com
wrote:

Thanks @felix-dumit! I've never worked with bluetooth before but it seems this is similar to location in that you need to set a few plist values in the project to get the permission to show up.

Can you add these requirements to the readme near the location information?

Reply to this email directly or view it on GitHub:
#40 (comment)

[felix-dumit]

I just noticed an issue with my current implementation. Even if the user rejects the system permission alert it will show up as allowed.

Since iOS doesn't need a permission for bluetooth to run in the foreground, just by presenting the alert bluetooth will be powered on and it will detect that it was accepted.
I don't know if there is any way to detect if the background permission was actually accepted.

[felix-dumit]

Fixed the previous issue on d182b62.
Now I'm looking at both the authorisation level for the permission as well as the current status of bluetooth (powered on, off).

[nickoneill]

Thanks @felix-dumit, the readme and the status work look good! Let me know when you're done with your additions and we'll get this pulled in.

[felix-dumit]

I think I'm done then, everything is working as expected for me

[nickoneill]

A couple things:

• I like your lazy initialization of the manager! I'm going to try to pull that into the location manager too for Can we make any managers lazy? #42
• Can you add the denied/disabled alert to requestBluetooth like the other permissions have?
• Move kAskedForBluetoothString up into PermissionScopeConstants
• Is there a reason to call requestBluetooth if askedBluetooth is true? Do we need to do the start/stop step before we can get the state from from the manager?
• When setting a value with NSUserDefaults, always call synchronize afterwards to make sure the change is saved.

[felix-dumit]

Response to your remarks:

• I think it's better because if the user is not interested in bluetooth we don't need to instanciate it
• Ok I'll add it
• Ok
• Yes in order to get the status we need to trigger an event for it. The logic here is that if the user has already been asked for the permission we need to do this to poll the bluetooth status, otherwise we can wait until the user requests it by tapping the button
• Ok I'll add that too.

[felix-dumit]

Also just in case you run into it as well: If you go to the settings and toggle the bluetooth permission the app will get a sigkill event, but apparently this is expected behaviour and the app relaunches itself afterwards: https://devforums.apple.com/message/714178

[nickoneill]

Thanks! This looks great now.