Can iOS receive iBeacon packet in sleep state and wake up the app?
I killed an app and restarted, then kept the phone in sleep mode. The device was was in beacon region when device reboot and I kept the device screen off after reboot.
My iOS app is not waking, so I suspect its not receiving iBeacon packet.
I checked the system log and found that the didEnterRegion procedure is not getting called.
Does app wakeup works incase of force terminated app and does iOS receive iBeacon packet in reboot and immediate sleep state?
If I make screen on then it starts working immediately but if screen is off after reboot its not receiving iBeacon packet.
Yes, iOS CoreLocation will launch your app on region entry or region exit, and works even after force termination after iOS 7.1.1. You will only get the appropriate callback if you set up your CLLocationManagerDelegate in the AppDelegate's didFinishLaunchingWithOptions method. If you do not set this up in that method, then CoreLocation will not know to make the callback after app launch.
Testing entry events across an app restart can be a little tricky, so here are a few tips to avoid pitfalls:
If is critical that your app think that it is "outside" the region when it was last running. If it was "inside" the region when it was last running, it won't necessarily get another entry callback because it will think it never left. When testing, make absolutely sure you get a didExit callback or a didDetermineState callback that says it is out of region before you kill the app or reboot. Verify this with a NSLog statement, a local notification, or some custom UI indicator added to a screen of your app.
If you reboot an iOS device, CoreLocation is not fully initialized right away -- I have seen it take 5 minutes after the screen comes on before I get any callbacks. Be sure you wait long enough.
Once CoreLocation is fully initialized, region entry events typically happen within one second of when the beacon comes into range. However, if the limited bluetooth hardware assist pattern slots are all full on the device (typically this happens if you have a few other beacon apps that have used them all), then entry events fall back to software scans that happen only every 10 minutes or more. An entry event can take that long in such a situation. Make sure you wait long enough before assuming it isn't working.
Related
I am newbie with iBeacon and need some help. Already found some useful info from other topics but still searching for answers.
Is there a way to receive notification about my state at position right after app is killed or after I switch ON bluetooth? Now I got notifications only after state changes.
Example: I need to have notification when I got to point 'A'. But I got there and realized that my bluetooth is OFF. I switched bluetooth ON and didn't get anything because iBeacon thought I am 'INSIDE' from beginning. This happens when app is not foreground (but not 100% times, sometimes iBeacon 'rescan' and send his state again).
I need to somehow manually refresh iBeacon state and get methods didDetermineState or didRangeBeacons to work. I tried to stop and start monitoring after app is killed to forces the notification, but doesn't seem it works. I know there is a way to get this 'refresh' after turning ON display, but it could be perfect to also get it in other situations when needed.
Lots of location and beacon events can wake up an app that is running in the background, but relatively few events are sent to apps that have been killed via the task switcher or were never launched since boot.
The only bluetooth events capable of launching a non running app are:
didEnterRegion (for CLBeaconRegions)
didExitRegion (for CLBeaconRegions)
Other events received only by foreground/background running apps:
didDetermineStateForRegion
CoreBluetooth device discovery
CoreBluetooth power state changes
The last one is the event you care about, but it just won't be sent to apps that are not running. One alternative may be to rely on other location events like Significant Location Change, which launches a non-running app when the user moves "significantly" (e.g. to the next cell tower). You could register for these events and check Bluetooth state at that time. This may be the best you can do.
I have an app that monitors iBeacons entry/exit events. When it receives an event it forwards the event off to a server. The app continues to work (e.g., the server continues to receive updates) after the user minimizes and/or force closes it (so it works correctly in the background).
However, after a phone has been away from any iBeacons for a sufficient amount of time (e.g., overnight) and is brought near iBeacons again, the app stops receiving enter/exit updates until the user opens it up again (brings it into the foreground). If the user minimizes/closes the app at that point, updates continue to work correctly in the background.
Is anything that I need to do to allow long running monitoring updates in the background? After a while does iOS stop background monitoring?
Note: I am running iOS 9.3.1
iOS Apps are supposed to be able to detect beacons indefinitely in the background when they have been granted "always" location access.
This is the second report I have heard like this, so I wonder if it is a bug or a change in a new iOS version. Reporting your iOS version would be helpful.
One possibility: the network calls may be being blocked and not the beacon detections. You could test this hypothesis by adding NSLog statements to :
Log on beacon detection
Log on successful and unsuccessful connection to the server.
Once you add the above, reproduce the issue where you don't see events on your server. Then connect your phone to XCode and go to Devices, and look at the recent NSLog output to see:
Is there a line indicating the beacon was detected?
Was the server connection successful or not?
If you find it is the network connection that is failing, you may be able to correct the situation by requesting additional background network permissions.
EDIT: One other thing you might try when a detection is not made is launching a different beacon scanner app in the foreground like Locate. This will force an OS bluetooth scan and it might kick off your app's detection. If this works, it would tell you that bluetooth scanning had been suspended across the phone.
I am working on an iPhone app that notifies a user when he enters in the region of an iBeacon.
I have a few question regarding the same:
From documents:
Monitoring launches app when entered in the region of iBeacon being
monitored.
But the behavior is:
It only works when phone is awakened i.e. When display is turned on.
But when app is not running and display is off nothing happens same is the case when display is on and user enters in the region of the beacon.
Is it possible to launch application when users enter/exits the region even when display is off or on not just when phone is awakened?
I checked this iBeacon Notification when the app is not running link, which shows it is possible. I am monitoring an iBeacon but not able to get the expected behavior. Am I missing something??
Any help is appreciated.
Yes, you can get notified on entering a region in the background. This will happen as long as:
The app has been opened at least once
The user did not kill the app directly (by quitting the process, not just dismissing it)
Now understanding how it behaves a a little more nuanced.
At my company we've done a fair amount of research on this. In fact a colleague of mine wrote a great blog post about the behavior: iBeacon Monitoring in the Background and Foreground.
What was unexpected was how long it can take to get a didEnterRegion in the background:
Condition Max time to detect a region change
-------------------------------------------- ----------------------------------
Phone awakened,notifyEntryStateOnDisplay=YES 1 second
Phone awakened, notifyEntryStateOnDisplay=NO NEVER
UIBackgroundModes=location ON up to 15 minutes
UIBackgroundModes=location OFF up to 15 minutes
There are a couple of properties you can set on a CLBeaconRegion to alter when your app will be notified about a change to the user's location in relation to that region:
notifyOnEntry - you will be notified via locationManager:didEnterRegion: when the user enters the region
notifyOnExit - you will be notified via locationManager:didExitRegion: when the user exits the region
notifyEntryStateOnDisplay - you will be notified via locationManager:didDetermineState:forRegion: when the user wakes their device's screen up and they are inside the region
Note that you must completely exit a region before didEnterRegion: is called again, and sometimes it can take a minute or more for the device to properly register that you have left a region. Because a beacon can broadcast up to 30 or 50 meters (or perhaps more), you either have to move a long way away from a beacon to leave a region or otherwise turn the beacons off , wait for a minute or so, and then back on to trigger a change.
Will iOS region monitoring launch my app in the background if the user enters a region that was successfully being monitored for prior to the app being terminated?
I know that the significant change API will do so and will let me know at launch time via the inclusion of the UIApplicationLaunchOptionsLocationKey key. If region monitoring will wake my app up out of a terminated state too, then what does the launch process look like? Is there a special key I should be looking for?
Yes, see Region Monitoring
In iOS, regions associated with your app are tracked at all times,
including when your app is not running. If a region boundary is
crossed while an app is not running, that app is relaunched into the
background to handle the event. Similarly, if the app is suspended
when the event occurs, it is woken up and given a short amount of time
(around 10 seconds) to handle the event.
I have been searching for similar answer, but came across this: Region monitoring in ios 7
Seems like if the app is manually terminated by the user in iOS 7, location notifications will not wake the app to process it. Apple employee has commented here https://devforums.apple.com/thread/209302?tstart=0
I am using core location framework inside my application and I set the location string in UIBackgroundMode or Required background modes(in Xcode 4.2) for getting the updated location from didUpdateToLocation method when app is running in background and also sending this updated location to server by hitting the specific link inside didUpdateToLocation method of core location framework.
My question is that will the app be terminated after some time when running in background or not?
No, there is no specific time defined for this.But app will definitely terminate based upon certain parameter - battery drain, memory footprint issue etc.
In developer documentation it is clearly mentioned - "The system keeps suspended apps in memory for as long as possible, removing them only when the amount of free memory gets low. Remaining in memory means that subsequent launches of your app are much faster."
Go through this for complete details -
http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
I am sure it is not useful for the author because the question was asked in June 2012 and I am giving an answer in June 2019. This answer maybe is useful for other users.
I am posting this answer because Everyone is said that it is OS default behaviour, We can not change it....bla....bla.
Recently, I was working with the same requirement. After 2-3 week hard
work, I did it. For other users, I create a helper class for it. My
app will never be killed by OS until the location tracking enabled.
You can also verify that OS will never kill this app tracking app
Use HSLocationManager for infinite location tracking in the active and inactive state.
Refer my app which is available in the app store(App will never kill by OS if location tracking is enabled)
Location manager that allows getting background location updates every
n seconds with desired location accuracy.
Advantage:
OS will never kill our app if the location manager is currently
running.
Give periodically location update when it required(range is between 2 -
170 seconds (limited by max allowed background task time))
Customizable location accuracy and time period.
Low memory consumption(Singleton class)
iOS app may get terminated due to following reasons:
Watchdog Timeout
As you’re probably aware, since iOS 4.x, most of the time when you
quit an iOS app, the app isn’t terminated – instead, it’s sent to
the background.
However, there are times when the OS will terminate your app and
generate a crash log if the app didn’t respond fast enough. These
events correspond with the implementation of the following
UIApplicationDelegate methods:
- application:didFinishLaunchingWithOptions:
- applicationWillResignActive:
- applicationDidEnterBackground:
- applicationWillEnterForeground:
- applicationDidBecomeActive:
- applicationWillTerminate:
In all of the above methods, the app gets a limited amount of time
to finish its processing. If the app takes too long, the OS will
terminate the app.
User Force-Quit
iOS 4.x supports multitasking. If an app blocks the UI and stops
responding, the user can double-tap the Home button from the Home
screen and terminate the app.
Note: You may have noticed that when you double-tap the Home button,
you also get a list of all the applications you’ve run in the past.
Those apps are not necessarily running, nor are they necessarily
suspended.
Usually an app gets about 10 minutes to stay in the background once
the user hits the Home button, and then it gets terminated
automatically by the OS. So the list of apps that you see by
double-tapping the Home button is only a list of past app runs.
Low Memory Termination
When subclassing UIViewController, you may have noticed the
didReceiveMemoryWarning method.
Any app that is running in the foreground has the highest priority in
terms of accessing and using memory. However, that does not mean the
app gets all the available memory on the device – each app gets a
portion of the available memory.
When total memory consumption hits a certain level, the OS sends out a
UIApplicationDidReceiveMemoryWarningNotification notification. At the
same time, didReceiveMemoryWarning is invoked for the app.
At this point, so that your app continues to run properly, the OS
begins terminating apps in the background to free some memory. Once
all background apps are terminated, if your app still needs more
memory, the OS terminates your app.
I have seen that the background location updates will work for several hours. But if I go to a place without reception the device will stop to send GPS updates it wont start when I go to a place with reception. This occurs after approximately 30min.
But if I add this, in iOS6, the app won't terminate
[locationManager setPausesLocationUpdatesAutomatically:NO];
Quick answer is pretty much no. Read below though for in depth.
Since multitasking has been enabled on iOS devices that a)your app gets allocated amount of memory and b)the device limits the amount of tasks, that is applications using memory, that occur at any given time. If you take an iOS device and open several apps you'll begin to notice that the app you opened first may have been terminated and reload from the viewDidLoad.
Generally it's safe to say if your app is a recently opened app (or even on a phone where someone clears the multitasking menu often) that the device will not terminate your application in the background.