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
Related
I have looked at some posts within this domain (e.g. iOS background fetch custom interval) and I am concluding that what I need to do is not possible.
I have an external device communicating to ios over bluetooth (NFC chip card reader). The external device goes to sleep if not pinged every minute (59 seconds).
When the app is in the foreground I can manage the pinging. When in the background I want to continue to ping. Is this impossible?
The ping operation is fast; it is just to send a message and I dont need a response back to ios.
(What works really well is the opposite, bluetooth communication can flow from the device to ios from the background. That is done via UIBackgroundModes in Info.plist to bluetooth-peripheral.)
Please note that I am feeding the iphone from external power in the application here. It is an industrial application; and the normal iphone usecase is not applicable.
Short answer, no. The best iOS offers is back ground fetch. But there is no guarantee when background delegate method is called. You can specify a timespan as a guide but it primarily based on how often the app is accessed.
https://www.raywenderlich.com/143128/background-modes-tutorial-getting-started
I'm using BLECommander to connect to a bluetooth device in the foreground and my code is heavily based off this sample app. I believe my app would use both bluetooth-central and bluetooth-peripheral. Additionally, I would ping in the background every couple of hours to retrieve any new missing data. I am fine with connecting to a device in the foreground; I simply want to send messages to it in the background and retrieve data.
I have read the apple documentation on using core bluetooth to operate in the background.
If you read the apple documentation, you should know that your options are quite limited on iOS on what you can do in general when your app is in background.
However, there could be ways to achieve what you want. If you have control over the other bluetooth device you can make it change the BLE advertisement from time to time. When you scan on iOS, you will also get a scan result in background (but only once for a certain advertisement!) and can then connect to the device and read/write.
Hope this helps!
I have got a chip that has a iBeacon service as well as a standard BLE service.
I would like to use the iBeacon service to trigger the app that I am developing when entering a BLE signal range.
Once active I'd like the app to scan for peripherals using CoreBluetooth and then connect to the chip.
Is this against Apple terms and conditions?
Apple has no known restrictions on this setup. In fact, this is how the RadBeacon configuration app works.
Using this technique, detecting a beacon in the background will only give your app 5 seconds of background running time, which generally is not enough time to reliably complete Bluetooth pairing and data exchange. Your best bet would be to present a local notification to the user on beacon detection, and then if the user brings the app to the foreground, do the pairing.
An alternative would be to extend background running time using a technique like described in my blog post here. That post shows how to range for beacons in the background, but the same technique will work for bluetooth communication tasks.
how is it possible to send data to an iPhone which acts as an iBeacon?
I am looking for an process as the following:
Search nearby iBeacons
Connect to some iBeacon
Exchange data between the devices
Does anybody know how to put the different bluetooth functions together to make
this possible?
thx in advance
Standard iBeacons are transmit-only devices that can be seen by mobile devices, but don't actually "connect" to them or exchange data.
But you can still do what you are asking if you have an app on all devices as well as a web service to do the data transfer. This would allow devices A and B to detect each other when they are nearby and exchange data. Here's how:
Your app on devices A and B alternates between acting as an iBeacon (advertising its presence with an application-specific identifier and a phone-specific identifier) and ranging for iBeacon signals including the application-specific identifier.
During its ranging cycle, your app on device A will detect an iBeacon transmission from device B, which includes both your application identifier and the device identifier of B.
App A then makes a "write" call to the web service with a source of "A" and a destination of "B", along with any data you want to transfer, like "Device A says hello to device B."
The app would also periodically make a "read" call to the web service. In this example, device B would read any information destined for B, and the web service would return a record that device A had send it a message with the data "Device A says hello to device B."
Because the same process is also running on both phones, this communication can happen both ways.
iBeacon is a proximity technology and isn't designed for data interchange. However, since the Bluetooth stack is going to be active on your iPhone acting as the beacon (so it can advertise its proximity UUID), you can use Core Bluetooth to connect to the beacon and exchange data between the devices.
Does it specifically need to use iBeacon technology? The reason I ask is that from reading your description of the process, you could achieve the same thing using iOS 7's Multipeer Connectivity. It's able to abstract out all the technical complexities of connecting 2 iOS devices together regardless of the interface, be it WiFi or Bluetooth. I've managed to build something similar using MCNearbyServiceBrowser, MCNearbyServiceAdvertiser, and MCSession classes.
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?).