As you know, after some period of inactivity, a Bluetooth device will disconnect from an iPhone. The user will then have to go back to Settings in order to reconnect the device.
1 - Is it possible for an iOS app (when it enters foreground) to force the reconnection to a paired Bluetooth device, without any user input?
2 - Is it possible to force the reconnection to a paired Bluetooth device, but during an app wake-up state from an iBeacon signal (matching UUID)?
Yes, you can use CoreBluetooth APIs to connect to a Bluetooth LE device without user input. It doesn't have to be "paired" in the same way as a Bluetooth Classic device. To do this, the Bluetooth LE device should expose a GATT Service UUID that the mobile app can recognize, and when it discovers this Service UUID, it can simply connect programatically.
When you use CoreLocation APIs to wake up your app based on iBeacon detections, the app is launched into the background temporarily. You can send a local notification to the user to try to get the user to tap on it and bring the app to the foreground, but if the user does not, app background rules still apply.
Bringing together #1 and #2, you should understand the rules Apple places on using CoreBluetooth in the background. See Apple's docs for The bluetooth-central Background Execution Mode. It would be possible to make a connection in the background if you get the proper app permissions.
Related
After the App is killed by the user, if there is a way to resume the previous BLE connection after ibeacon waking up?
In my iPhone application, I could manage to wake up the app using iBeacon after the App is killed by the user. I could trigger local notifications during the wake-up period, but when it comes to BLE related tasks not there is no response at all. No scan callback no connect callback.
Edit:
The BLE background is enabled.
It scans for a peripheral with the identifier that is previously bonded with iPhone. The identifier is store in Userdefaults.
For pending connection, when the App is killed, it will call the disconnect callback. No pending connection I guess.
I haven't config the BLE state restoration yet.
Thanks Paulw11 and Prakash Shaiva
After exploring more documents online, here is the answer:
In my case, I want to wake up the App after being killed by users. And build a connection with a previously bonded BLE device.
First thing I learn
When iOS App is waken up by ibeacon, it will not call willRestoreState callback. In other word, App cannot restore connection from state restoration support. But we could attempt to build new connection instead.\
willRestoreState callback calls when your App is killed by iOS system.
Conditions for Bluetooth State Restoration to relaunch your app
See answer from Apple
Second thing I learn
In order to build new connection during the wake up period, an array of service UUIDs that you're instersted in need to be added to func scanForPeripherals(withServices serviceUUIDs: [CBUUID]?, options: [String : Any]? = nil), otherwise the random scan will be stopped by iOS itself.
I have a device, located in a Wi-Fi local network possibly without Internet connection, which sends notifications to the devices that are connected to it using a web-socket.
But when I lock the phone or press the home button, my application goes to background mode and the web-socket connection gets closed, so since then any notification doesn't get to the phone.
I know I can do this by using remote notifications (with Apple Push Notification Service), but my device is intended to work on any Wi-Fi network (with or without Internet access) or generating its own Wi-Fi access point (and therefore without Internet access).
So the question is: Is it possible to have a persistent connection, like in Android where I can maintain a connection in a background service?
No, you can't if you want your app in the App Store.
If not (for example this is an Enterprise app), you can use kind of hacks, like silent audio or voip but this will drain battery a lot.
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app
Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP).
Apps that need to download and process new content regularly
Apps that receive regular updates from external accessories
unlimited backgrounding on ios with silent audio
Apple docs - background execution
What I want to do is to notify user from background that something happened. On iOS device this is done using UILocalNotification. I also have an app on pebble watch to which I send a notification and user can interact with it.
The issue is that starting with iOS 8 pebble also shows all notifications from Notification Center, this way the notification gets duplicated.
To make things worse, pebble actually creates two different connections: (1)a simple Bluetooth link for normal communication and (2) a BluetoothLE for ANCS service: this means that the watch can be "connected" but no connection for ANCS services is established.
Is there a way to determine this, so that I don't send the notification manually if pebble already receives it from ANCS services?
p.s. I do check if the device has BLE (using CBCentralManager), so this partially solves the issue - I send manually the notification for the devices that don't support BLE at all.
I heard about iOS it self wouldn't allow an app to stay longer while its in background. I don't know exact minutes but how I can active my app to handle video / audio calls or for chat functionality. I'm using Quickblox iOS SDK for video/audio calls and chatting.
P.S. I've successfully implemented this functionality only worry about background? Is there a way in Quickblox SDK to achieve this?
Any help/suggestions would be highly appreciated.
Here is the list of the application where you can perform actions or keep alive your app while your app is in background.
Audio and AirPlay
The app plays audible content to the user or records audio while in the background. (This content includes streaming audio or video content using AirPlay.)
The user must grant permission for apps to use the microphone prior to the first use; for more information, see Supporting User Privacy.
Location updates
The app keeps users informed of their location, even while it is running in the background.
Voice over IP
The app provides the ability for the user to make phone calls using an Internet connection
Newsstand downloads
The app is a Newsstand app that downloads and processes magazine or newspaper content in the background.
External accessory communication
The app works with a hardware accessory that needs to deliver updates on a regular schedule through the External Accessory framework.
Uses Bluetooth LE accessories
The app works with a Bluetooth accessory that needs to deliver updates on a regular schedule through the Core Bluetooth framework.
Acts as a Bluetooth LE accessory
The app supports Bluetooth communication in peripheral mode through the Core Bluetooth framework.
Using this mode requires user authorization; for more information, see Supporting User Privacy.
Background fetch
The app regularly downloads and processes small amounts of content from the network.
Remote notifications
The app wants to start downloading content when a push notification arrives. Use this notification to minimize the delay in showing content related to the push notification.
If your app will be performing one of the above tasks just add related key into your plist file. For more check official Apple docs: https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
Can an iOS device scan for presence of Bluetooth LE devices while locked and then respond to them by opening the app?
The scanning can definitely happen in the background.
In order to get the functionality that you're talking about the comment by owen is correct. I'll expand on it a bit.
What we do is when we recognize a BLE device that we're interested in and would like the app to open we send information to our server, from where we have the option to send a push notification if the user wants. This could probably also be achieved with a local notification set a few moments in the future. From there the standard rules apply for push notifications, if they opt to look at it your app can be opened and you can respond to the proximity of the BLE device that initially triggered. The user always has the option to ignore the notification though.