I guess it is a background mode related to ExternalAccessory.framework.
But the document about External Accessory says, "If your app is suspended in the background when an accessory notification arrives, that notification is put in a queue. When your app begins running again (either in the foreground or background), notifications in the queue are delivered to your app. Notifications are also coalesced and filtered wherever possible to eliminate any irrelevant events. For example, if an accessory was connected and subsequently disconnected while your app was suspended, your app would ultimately not receive any indication that such events took place.".
This means that the external accessory communication will be just queued until the app enters foreground mode, But the other background modes like Location, Bluetooth LE are working as real-time in background mode. So I doubt that just queued is the only thing that can do. Is it really?
If your external device is "Made for iPhone/iPod/iPad" - MFi you can use this option. It's not for BLE communication.
Related
I have implemented Agora call in iOS app which works perfectly fine when app is in foreground ... Actually in my case we initiate call through Bluetooth BLE iBeacon. Along with this we call an API which is also working fine.
Problem is when app in background or when phone is locked ... Even when app is in background, app listens bluetooth event and Call API but it never start Agora call until we bring app to foreground. Means call works in foreground or it waits to start call when app enter in foreground.
To handle this I implemented local notification to prompt user to tap notification and bring app to foreground. But we want to do it through Bluetooth iBeacon. That instead of user to tap notification, it press beacon button to bring app in foreground and start call. On beacon button press I can catch the event in background as well but unable to bring the app to foreground.
Could not find some solution of it. But seems like its do-able as with Car tablets which are connected with bluetooth to phone we can dial a number on tablet and through bluetooth communication with phone it makes a call to selected or dial number even when phone is locked.
Means third party bluetooth devices can send command to locked phone and initiate call.
There are two ways using that you can make calls when app is in background or in locked state even your app is in killed state.
Using CallKit Framework provided by apple.
You can send custom push notification to the user and on click of push notification application is wake up and call is happen.
I've designed a very simple wearable BLE device with one physical button. This device has a UART Service and can notify a connected device when the value change (when the button is pressed).
My goal: The smartphone must be able to send an HTTP request in background every time the button is pressed. even when the app is not running.
For this need, I have to implement the iOS Bluetooth background process with CoreBluetooth. But before, i would like to know if CoreBluetooth can meet my need.
So my questions are:
Is it technically possible to keep a long-term background connection between Smartphone and BLE device, even if the Smartphone reboot.
Can I wake up or start my app in foreground (without notification) when the BLE device button is pressed.
And if the previous statement is not possible, can I execute a very basic HTTP request in background when the user press the button ?
Thank you for your help!
I'm developing a BLE enabled App. In my App iPhone operate in peripheral mode with Bluetooth accessories. Everything works fine until I go to background Mode Because my Phone is working as peripheral so It also update accessory with battery level it doesn't work in background because app will only wakeup once accessory will send request because its already subscribe for the update I somehow have to wakeup my app in background mode and send update let's say every x minutes .
I have already enable Bluetooth LE accessory background mode.
Apparently enabling background mode only gives the 'right' to run in the background whenever there is an event triggered.
One of the method is what you already did by 'polling' from the accessories periodically by sending request to wake up the app and execute the task.
Another way is to use background refresh. The only downside of background refresh is the event will not occur at specific period. It was mentioned at about 10-15mins typically or it might tag along with other app background wake up. If the update is not very frequent or crucial, this method would probably better for your case.
You can keep your app running in background by setting the "required background modes" option in your plist. Select "App communicate with accessory".
Please see the attached image for reference
My application currently uses the application:didReceiveRemoteNotification:fetchCompletionHandler and application:didFinishLaunchingWithOptions: delegate methods to handle background remote notifications. Intermittently, a push notification will appear, and I will not receive a log that says that it has called either of my application delegate methods. I have tested for suspended, active, background, and suspended states, and they all seem to be working correctly. About 1 in every 30 pushes I get a 'dead' push notification.
****NOTE: This case only happens when I do NOT enter by touching the push notification, and happens unpredictably.**
The error came from an iOS 8 "feature" in Apple's docs. If an iPhone has less than great cellular or wifi signal, low battery, or is not plugged into a charger, the phone will receive the notification on the lock screen, but will not launch the app into a suspended state. Therefore, background events such as application:didReceiveRemoteNotification:fetchCompletionHandler will not be fired IF you do not enter directly into the application by swiping the notification itself.
This was offset in testing by the fact that the device was always plugged into my development machine during debugging with a strong wifi signal, so I would never be put into a bad state.
This is extremely specific, but crucial if your app relies heavily on push notifications for background functionality.
Currently am working with the project using core bluetooth. In which am using background mode communication, am able to receive the notification when ever app running in background but we have only one service and one characteristics for data communication based on frame type we are able to identify the frames which is received.
For background mode i used this code
[centralManager connectPeripheral:activePeripheral options:#{CBConnectPeripheralOptionNotifyOnConnectionKey: #YES,
CBConnectPeripheralOptionNotifyOnDisconnectionKey: #YES,
CBConnectPeripheralOptionNotifyOnNotificationKey: #YES}];
its working fine for both event and session background.
Event background alert shows for every notification is there any way to hide the alert for every notification show only needed.
Thanks
In event mode the alerts are generated by the system and as long as your app is not activated, it can't do anything about them.
In session mode the app stays responsible for handling all these events. It receives all the callbacks just as in the foreground. If you want to minimize the disturbance of the user, you should take over the alert generation with this mode.