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.
Related
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.
I have an iOS app that is communicating with a bluetooth peripheral. When you tap a button on the peripheral, the app should start recording, whether it's in background or foreground.
Furthermore, there will be multiple recordings, in order to send them quickly to the server. So the app will record in chunks and then send them to the Parse database that I set up.
The chunk recording and uploading parts are working fine, but I have problems while the whole process starts in background, due to the bluetooth notification. The code that starts the recording is executed, but the completion block of the upload process is not. Maybe the recording starts but never finishes because the system stops the execution, since the app is in background?
I added the audio background mode so the app will be able to record in background, and I also added the voip background mode, since I read it will enable background network activity (which is something that I need in this case).
Unfortunately this didn't work.
Any suggestions will be appreciated.
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.
I have an app that makes heavy use of video out. In a typical use-case, I'll have an iPad connected to an external monitor. I just want the external monitor on; the iPad display does not need to stay on.
The ideal case would be for someone to connect to an external monitor, then lock their iPad. But that pauses my app. (Currently, I'm calling setIdleTimerDisabled to keep the iPad from locking up and pausing my app.)
I'd like to give the user the option of locking the iPad, but still having my app running and sending images to video out. (Note: I'm not talking about keeping my app running when it's not in the foreground. I just want to keep it running while it's in the foreground, but the device is locked.)
Is this possible?
I would say no, it is not possible. Here's why:
The docs read:
Pressing the Sleep/Wake button is another type of interruption that causes your app to be deactivated temporarily. When the user presses this button, the system disables touch events, moves the app to the background but sets the value of the app’s applicationState property to UIApplicationStateInactive (as opposed to UIApplicationStateBackground), and finally locks the screen.
Something interesting to note in the docs above is that a bit further down under "What to do when an interruption occurs" Apple recommends that you stop doing certain tasks.
In response to this change, your app should do the following in its applicationWillResignActive: method:
Stop timers and other periodic tasks.
Stop any running metadata queries.
Do not initiate any new tasks.
Pause movie playback (except when playing back over AirPlay).
Enter into a pause state if your app is a game.
Throttle back OpenGL ES frame rates.
Suspend any dispatch queues or operation queues executing non-critical code. (You can continue processing network requests and other time-sensitive background tasks while inactive.)
This tells me that Apple doesn't want or expect your app to be doing much of anything in this state, other than preparing to be fully backgrounded.
On a related note here's a thread that shows how to determine whether you've hit the Sleep/Wake button or not:
Is it possible to distinguish between locking the device and sending an app to background?