I have specific requirement where i want to fetch data from the connected Ble Device every 15 mins for a period of time like form 10:00 PM to 10:00 AM. Can it be done when my app is in background and device is locked. Obviously, user won't keep the app in foreground for so long. Any suggestions on how to achieve this.
It may be achieved but unfortunately you need to solve this from device perspective.
Your device will need to wake up and initiate connection with your phone whenever you need to sync data. It will wake up your application and even launch it if it was terminated. You can then initiate a standard background process for which you have limited time to do whatever needs to be done. When complete you should disconnect from your device and wait for the process to be repeated.
There might be some hacks like using silent push notifications to wake up your app and try to connect but Apple will most likely not allow this plus there is a great chance your BT will simply not work in that state. Still it is something to try if you really need it.
You have the problem that you can't have a timer in an iOS app. Therefore you have some options that require specific behaviour of the peripheral.
One option is to let the app first connect, and always upon disconnect, it tries to reconnect. Then simply make the peripheral don't advertise for 15 minutes. As soon as it advertises again your app will be woken up because it connected. You can then fetch your data.
Another option is to be constantly connected and have a timer in the peripheral that notifies data every 15 minutes.
Both options requires you to have background capabilities enabled in your app and State Preservation and Restoration.
In background mode(app was killed) iOS device cant communicate with BLE.
Only scan BLE device which have service uuid.
Only background scanning is possible in iOS.
So u can get notification while peripheral was found in Background mode.
Related
I built a simple ios app with IBeacon . I ran this app on an iPhone 4s whit ios7.1 while running an IBeacon base station.Everything is working right in background or foreground(exit region have 30 seconds delay in background).But over a period of time,about 3 hours,this app can not monitor any event though device setting were not change(blueTooth and locate is normal).This situation must restart the device.
Please tell me what should i do aboult this situation?
Thanks!
I wonder if iOS Bluetooth scanning is slowing down when your app is in the background such that it appears that events never fire because they are just taking so long to happen. Rebooting may speed up the cycle.
One way to force a Bluetooth LE scan cycle to look for iBeacons is to run a different app in the foreground that uses the CoreLocation iBeacon ranging APIs.
Try installing Locate for iBeacon, then as soon as your app appears to be not getting notifications in the basckground, launch Locate for iBeacon and tap Locate iBeacons. Do you see iBeacons? Does your background app get a notification?
If this works, then repeat the test and instead of using the Locate app to force a scan, just wait (an hour if needed). See if you eventually get your notification anyway, and note how long it took.
Edit: it appears that this is a case where iOS stops looking for iBeacons entirely requiring a reboot. See related question below.
iBeacon: didRangeBeacons stops getting called, must reset device for it to work again
I am developing an app which will communicate with bluetooth low energy devices. And I am displaying the heart rate in UI. It works fine in foreground and background while bluetooth is in connection. But my problem is that while connection of bluetooth device lost longer while app is in background, my app crashed. showing the crash report as :
MyApp[565] has active assertions beyond permitted time:
With Core Bluetooth background communication must be implemented either with characteristic change notifications or indications. You are keeping the app running for too long after being brought to background and iOS is killing it forcefully. I suppose you are using the beginBackgroundTaskWithExpirationHandler: method to keep some timers running. This doesn't work for long periods of time. The limit is around 10 minutes but it may depend on other factors too.
The Core Bluetooth Programming Guide contains a pretty concise description of how backgrounding has to be handled. Practically, your app needs to subscribe on either notifications or indications of the heart rate characteristic and react to it only when the callbacks happen. The app should keep running when backgrounded only if it is doing some uninterruptible task, e.g. non-resumable network operations.
i am assuming that you are on iOS 6.1
Are you handling device disconnect using the following delegate methods of CBCentralManager
– centralManager:didDisconnectPeripheral:error:
– centralManager:didFailToConnectPeripheral:error:
also i suspect there is no device discovery when in background, so you might have to handle that logic in your code
I have noticed that some apps e.g. Skype run in the background.
I would like to have my app run in the background also, waking up every 1 seconds to update some data and then going to sleep again.
How can I do this?
I gather that NSTimer's do not work in the background.
You can't. Voice-over-IP apps get a special exception for this, basically the system manages a network socket for them and wakes them up if there's data. There's no way to do the same with a timer.
By the way, waking your app every second, your battery wouldn't last half a day.
See Executing Code in the Background
You would need to use push notifications to push information to the app (like the Facebook or Skype app). See this documentation from Apple on how to use push notifications.
Not every second though, that would drain the battery. Other than that, there isn't really a way unless you are running a VoIP app.
I'm thinking the answer to this is no, but does anyone know if a Bluetooth connection can be maintained in the background with iOS? I'm thinking I might be able to keep it around with the finite-task background API, but I haven't found anything indicating whether that's true or not. Another option would be to use GPS notifications and just reconnect every time the app gets a location changed notification.
You a right. It's a NO.
But if you use location change notification to wake up your app, you may have a short period of time to use Bluetooth.
I think that the Bluetooth connection should be maintained, but if your bluetooth application is not the foreground application it will not receive any data / commands, when it becomes foreground it will.
It is possible, I use this trick to allow an App to use foreground APIs for iBeacons to allow the app to range even when the App is in the background.
To range for iBeacons it uses a high power API and as so this is restricted to only run when the App is in the foreground and stops all delegates being called once the App enters the background.
By playing a silent audio file and adding the AirPlay capability to your plist it allows your app to run in the background just as it would if it was in the foreground.
I'm not sure if it will work for your case but as iBeacons do use the Core Bluetooth and Core Location frameworks it might just do what you are asking.
http://yifan.lu/2013/12/17/unlimited-backgrounding-on-ios/
Note although this trick has not been patched by Apple in iOS8 beta 5 it is possible they will in an update.
If you're using iBeacons, there are built-in APIs for handling when you enter/exit a beacon region, and you typically get ~5 seconds to range for beacons at that point before the app is put to sleep. Theoretically, you could start a background task w/ expiration handler that might allow you to range for ~30 seconds while backgrounded, but I have not verified this is the case. I do know that the background task can be started when normal CLRegions are entered/exited while in the background, and there is functionally no difference between CLRegions and CLBeaconRegions in terms of region monitoring, so if I had to guess I would say this is more-than-likely possible.
I'm having trouble keeping wifi from disconnecting after 30 mins in an iphone app that needs to function when locked by the user.
The app normally does not sleep, but if the user so chooses they may lock the display. I'm adding a new feature to the app that sends data out over the network at 1 second intervals. prior to this there has been no network requirement for the app, and it has functioned as desired (music, timer-based processes) while user-locked.
The answer seemed to be here:
Wifi connection doesn't stay alive when asleep, with iOS4
But adding UIRequiresPersistentWifi boolean to info.plist doesn't keep it from timing out the wifi (i'm testing on Touch, iOS4.02) after 30 mins, even while the app is busy sending data out over the connetion. Maybe this only applies if the display sleeps itself, rather than user locks?
Related, I think there is no way to "stir" the display at any interval? User pressing the home button is sufficient to bring back the wifi; unlocking is not necessary.
Also, I've read on the interwebs that it was stated in a WWDC that UIRequiresPersistentWifi applies to keeping alive 3G as well. Can anyone verify?
thanks
Your app may be getting suspended by the OS after a long enough period of user inactivity.
Under iOS 4.x there are certain types of apps that aren't suspended when the display is locked (music player, VOIP, etc.) Apps that register as a VOIP type app might be allowed to keep a persistant network connection over a longer period. However Apple may require that an app actually provide some VOIP functionality in order to register for that type in any app submitted for review.
Is there some activity that you need to perform network activity? From iOS5 onwards, we have noted that even if we send network packets (heartbeat timers), then also iOS 5 blocks it after locking device.
It is to be noted that services which requires VoIP continue to receive calls, and notifications do come when your phone is on sleep mode or locked. This means that WiFi is not totally closed. I dont know how this happens.
As an alternative you can use data carrier of your network provider as an alternative to WiFi in case WiFi has gone down. With UIRequiresPersistentWiFi, you just inform iOS5 that you would require WiFi to run your application, nothing else signifies whether it keeps your screen ON or OFF. For keeping your phone from autolock you can however use disableTimer = YES flag, in lieu of your battery charge.