I'm making simple iOS messenger with XMPPFramework. So the problem is, that if i app goes into background it's disconnects from XMPP server, so the only way to store incoming messages without opening app is Push-notification (add message var into push), which is not so good way.
Also, ma app make phone acting as iBeacon to track locations of other near phones. As i know, with such capability app can stay active even in background, but can i also hold's XMPP connection while i'm in background, tracking iBeacons? Or Apple finds out and reject such app?
Thanks for help?
It is important to distinguish between an iOS app running in the background and one that has been suspended.
Yes, you can use beacon trasmissions to keep your app alive in the background. When it is alive, you can do networking events in the background including XMPP calls.
There are limits to how long a beacon detection can keep an app alive in the background.
On the receiving side, by ranging and monitoring for beacons at the same time, you can keep it alive for 10 seconds for each new beacon region that appears/disappears, and you can extend this to 180 seconds on request. It is possible to game this system by rotating the beacon transmitted every 2 minutes to ensure there is always a new entry/exit event.
On the transmitting side, iOS devices can only transmit iBeacon packets when they are in the foreground. So the best you could do is keep the receiving app alive in the background and communicating with XMPP whenever there has been another app in the foreground within beacon range (~50 meters) within the last 3 minutes.
Related
How to keep scanning for BLE Sensors while App is in the terminated status in IOS App. While App is running I am able to manage multiple sensors. However, when App is terminated, how to keep listening to an advertisement and connect the Sensor to App not running status.
State preservation and State Restoration is implemented. Background mode Bluetooth-Central is turned on
I want to achieve it like Tile and Chipolo are doing in the terminate state.
What you are trying to achieve is not possible with normal ble capabilities:
Apps that support background execution may be relaunched by the system to handle incoming events. If an app is terminated for any reason other than the user force quitting it, the system launches the app when one of the following events happens:
Refer to Understanding When Your App Gets Launched into the Background
The way tile works is by using the iBeacon standard (my best guess).
An iBeacon is substantially a BLE. Your app can start a Region Monitoring for an iBeacon receiving region events (enter, exit). These events would wake your app also if the user killed it. When your app is awaken by a region enter event you have 8 seconds (give or take) to execute code and react to the event. Within this time you can start a standard BLE connection to use your iBeacon as peripheral and keep your app reactive to BLE events.
Of course your peripheral must be designed to support such behaviour.
I'm in the process of developing an iOS app that uses iBeacons.
I understand that my app can get woken up to the background when an enter event is triggered (when the iPhone detects a iBeacon with a certain UUID).
Can I use this to send back a beacon signal myself? (All while the phone is locked)
I know that my app would only have a few seconds in the background after being woken up by the enter event, but normally this should be enough time to send a beacon signal.
Any help is highly appreciated. Thanks in advance.
Unfortunately, an iOS device cannot send a standard iBeacon transmission when in the background. While you can execute the code to do so, and iOS will transmit, background transmissions will.not be detectable as iBeacons by other devices.
Why? CoreBluetooth uses a proprietary technique to roll up all Bluetooth advertisements of background applications into a single advertisement. This is designed to work with advertising Gatt services, and it has the side effect of breaking the iBeacon format.
I understand any iBeacon application can continuously run in the background, if CLLocationManager is appropriate used; we were able to get it working based on the thread iBeacon monitoring and ranging in background. From the thread iBeacon Notification when the app is not running it appears when phone is restarted, we get the notifications from the underlying API if the app enters into the proximity/zone of the previously specified UUID (bcos iOS briefly invokes our app).
Based on above 2 threads, I am assuming we should be able make ranging happen continuously in my app. We want to be able to read RSSI always (even if user restarts phone or moves out/in of the zone).
How can I make ranging happen 24 by 7 (even if user restarts phone)? I know cellcontrol has done it https://www.youtube.com/watch?v=BvJJjBspP-4
From http://blog.venmo.com/hf2t3h4x98p5e13z82pl8j66ngcmry/2014/7/8/introducing-background-nearby-with-ibeacons, they suggest that they were able to forcibly bring app into the foreground:
"Whenever a device enters a beacon region, it briefly launches the Venmo app into the foreground in order to broadcast its peer identifier over the MPC framework, thus establishing a Nearby connection. In other words, whenever our users open Venmo to pay or charge the people they are around, they can instantly emit a beacon signal that momentarily wakes up their friends’ devices to connect and populate the user's Nearby drawer."
Every post on here about this suggests this isn't possible. Can someone explain?
I suspect that "foreground" is a simplification and that Venmo actually takes advantage of the iOS location background capabilities (the iOS location background mode is also applicable to iBeacon); meaning the app doesn't actually enter the foreground, but is launched into the background to complete the necessary tasks even if the app has been terminated.
Here's a bit of info from the docs about iBeacon background usage: https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW7
I have worked on an app which read heart rate from server kinds of bluetooth low energy HRM(Heart Rate Monitor)by bluetooth notification.
And I have added the "App communicates using CoreBluetooth" into the app's "Background Modes".
It works fine when the app is in foreground, but when the app is in background, one of the Heart Rate Monitors is always to be disconnect with the app in sever minutes.
So I debugged the app and find that, this kind of HRM is always push notification irregularly.The interval between notifications is from 1 second to 20+ second.
I know that when the app is in background, iOS will stop the bluetooth connection if it is too long between bluetooth notifications.
So my question is: Is it possible to keep the connection when the app is in background?
Is reconnection the only way to solve my problem?
Detecting the disconnection and reconnecting to the peripheral will make your app more robust as it will handle the case where the peripheral goes out of range and then returns in addition to the case you are seeing.
When the peripheral is disconnected your centralManager:didDisconnectPeripheral method will be called on your delegate. In this method you can call connectPeripheral:options again to re-establish the connection. iOS will either do this immediately if the device is still in range or automatically later, once the device comes back into range.
Once your centralManager:didConnectPeripheral method is called you can re-establish the characteristic monitoring.
Edit Clarify that you can call connectPeripheral immediately