We were looking for a few roles regarding the Bluetooth LE in iOS, but we could not find them. I have a few questions for anyone who is already using it:
I have read here that there is the ability to listen in the background for the signals, is that right? if so, can i get a signal and open that app from background ?
The other way, can my app run in the background and at some point (lets say when the app gets a notification from alarm) send LE signal without even open the app ?
(Its reasonable that yes, because the iPhone DOES call delegate function, that i can write a LE into it, isn't it?)
Does LE Bluetooth control any iPhone operation(s) outside the relevant app?
Does the Apple docs has some kind of ordered roles for the LE?
Yes. But you can't bring the app to the foreground. You can do some background processing and post a local notification.
Not from an alarm, because the alarm would notify the user, not the app. Possibly from a push notification but that would be a bit weird.
Depends. iPhone can act as Central and Peripheral so it could.
? (You mean Central and Peripheral roles?).
Related
I'm working on a device that keeps count when a door is closed. What I'd like to do is when I walk through the door, my iPhone automatically syncs the data on the device and sends that count to the server (via iPhone) without me opening the app or having it in the background. Is this possible, if so how?
Here's a diagram of what I'm thinking:
Door closes -> BLE notifies iPhone -> BLE sends count to iPhone ->
iPhone sends that value to server
All without the user (me) touching my device or opening the installed iOS application.
Your app has to be running in the background to do something, but that is OK, because Core Bluetooth background mode will take care of that for you.
First, you need to select "Uses Bluetooth accessories" background mode in your project.
Now, your program flow will be something like this:
Your user runs your app which scans for available doors and displays them to the user
Your user selects a door that they want to connect to
You save the identifier of the selected peripheral somewhere like NSUserDefaults
You connect to the peripheral
Once you get a call to the didConnectPeripheral delegate method you can read the count and update your server once you get the value
The user can now suspend your app and do something else
Eventually the peripheral will go out of range and you will get a call to didDisconnectPeripheral. In this method you immediately re-issue the connect to the peripheral.
Since you have Core Bluetooth background mode, when the peripheral is eventually seen again you will get another call to didConnectPeripheral in the background, and you can proceed as per step 5 (In this case your app is already in the background so it will just go back to suspended state after you have read the data without the user doing anything).
You update the server in step 5. This step executes regardless of whether the app is in the foreground or background. The user doesn't need to open your app.
Now eventually iOS may remove your app from the suspended state, say due to memory pressure. In order to still be able to connect to the peripheral when it is seen you need to opt in to state restoration as described in the Core Bluetooth Programming Guide
If you are up for building your own circuit board and Bluetooth LE firmware, this is pretty straightforward:
Add a contact switch that sends a voltage level change to the circuit board whenever the door opens.
Increment a counter on the microcontroller when the level changes.
Write firmware that advertises an iBeacon packet with the counter as the least significant part of the iBeacon identifier (32 bit major and minor).
A phone can then pick up this counter by using CoreLocation APIs to both monitor for the beacon (for fast background wakeups) and range for it (to read the specific identifier), then sending the counter value to the server based on the identifier read.
The advantage of using CoreLocation instead of CoreBluetooth as #paulw11 suggests in his very good answer is faster background wakeups of the app, allowing an app to reliably read the counter in the background. With CoreBluetooth, this background wakeup can be much slower, and door open events are more likely to be missed.
SO. Initial data:
Device Xiaomi Mi Band 1 or 1S
Device paired with iPhone
Xiaomi iOS app has option "Vibrate on incoming calls"
How they implement it? It continue works if you reboot device or force quit an app. It is unusual for default BLE background. Any ideas how this app handle events?
For people who vote for closing this question. This is a very interesting issue which require some specific knowledge about bluetooth and background. For example there are three bluetooth background modes: external-accessory for old-school non-ble blueooth, bluetooth-central and bluetooth-peripheral. I have done a lot of experiments about last two. But it does not work as you expected after documentation reading. I have found few questions about this topic here on SO. All of them report about pure predictable for bluetooth background. And after all hours on this issue you see on Mi Band and them official absolutely legal app in App Store. And this App keeps connection or has some other "magic" mechanism to handle calls and initiate reaction on device. At a minimum it is curious. Is it? At a minimum it is useful for developers who works with peripheral devices.
It looks like Apple Notification Center Service (ANCS) integration, not Bluetooth Background + Core Telephony.
The purpose of the Apple Notification Center Service (ANCS) is to give Bluetooth accessories (that connect to iOS devices through a Bluetooth low-energy link) a simple and convenient way to access many kinds of notifications that are generated on iOS devices.
Documentation
CategoryIDIncomingCall is about incoming call
I am working on developing a bluetooth peripheral to work with my iOS device. I need to make the iOS app receive data whilst it's in background and process that data as it comes. Looking through Apple's CoreBluetooth framework, I can see how the background execution modes can be used. Now to save power, I want the iOS device to only connect to the bluetooth peripheral at a certain time (without need of user interaction). I've looked through Local Notifications on iOS and it has very limited functionality and don't think it provides what I need.
So is there anyway to wake up an app at 6pm and ask the application to start scanning for bluetooth devices? And then execute other code once device is connected? All this without user interaction.
Any suggestions would be appreciated!
Thanks!
You can't really schedule operations to occur at a specific time in iOS (aside from local notification, which as you said isn't what you need).
You can use background fetch mode to periodically allow your app to check for new data. You can set an interval (although this is only a guideline to iOS, not a strict schedule) for how often your app is woken.
When iOS calls your app delegate performFetchWithCompletionHandler method you can check the current time and decide whether you want to transfer data. If not then you can quickly return UIBackgroundFetchResultNoData. If you do get new data then you can retrieve it before returning UIBackgroundFetchResultNewData
I have a bluetooth device which is connected to the iPhone and has a control button. Pressing this button should make the app to perform a phone call to the previously defined number and establish a voice connection with the device (like bluetooth headset).
From what I've learned, it's not a problem when the app is active, but if it's not? 99% of the time it will be in suspended state. Documentation says, that a bluetooth device can wake up the app from suspended state to perform some data processing etc. But I couldn't find the info about phone calls.
As I understand it, the app can be waken up and perform a phone call, but this is critically important and I need to know for sure, so any information on the matter is greatly appreciated.
You can't use the app to perform the call when it's not active. Instead, you should use Apple's handsfree protocol for bluetooth to perform the call on the bluetooth device itself.
Hello I do hope someone can help me with this question as i thought it would be easy at first!
I'm a studying EE student who is not that good with code but trying!
Let me tell you my goal at the end of this.....
I would like to be able to open an app on the iPhone and then execute a bit of code to send a message, all via Bluetooth.
I would like to be able to pair this small Bluetooth device to the iPhone only once and be able for it to be in sleep mode (500 nano amps :D awesome) and when I turn it on (via a small switch) it will open an app and send that message. (the app is already done, you just have to press a button on the app in order to send the message, that's why I would like to use a Bluetooth device so you don't have to have the app open at all times!)
Sorry for the long paragraph but I need help! I have the Bluegiga BLE113 dev kit and im overwhelmed with all the information they give you! But I don't see anywhere where I connect to the iPhone and do what I want to do.
Has anyone done this before, can you steer me in the right direction?
As long as the person downloading the app has previously opened the app and they've agreed to backgrounding capabilities, then yes you can send the message in the background (if already connected). However, you cannot force your app into the foreground on a non-jailbroken iOS device.
Check out the BLE Transfer App sample code to get you started.
I guess what you need is:
the periperal implements the peripheral role
the app implements the central role
the app is trying to connect to the peripheral continuously (connectPeripheral:options:)
the peripheral wakes up on trigger and the phone connection request completes
the peripheral signals to the central using a characteristic change notification
the app receives the notification and executes the business functionality of your desire
the peripheral goes to sleep again
the app receives the disconnect event and starts a connectPeripheral:options: immediately
the app should utilize the new restoration feature of Core Bluetooth (watch the WWDC 2013 session 703 video)
This is just an outline and you need to know lots of small things to get it right. I suggest you try to go ahead and implement piece by piece and if you get stuck, ask a new questions. As #tdevoy suggested, the BTLE Transfer App is a good starting point. The Heart Rate Monitor is also a good source of info (OSX API is the same as the iOS).