The SDK of Estimote allows users to range for beacons based on proximity even when the app is in the background. Apple only allows it to range for beacons based on proximity on the foreground. My question is, is there a way to mimic Estimote when it comes to range with a proximity in the background?
Apple's CoreLocation framework actually does allow you to range in the background, but the time you are allowed to do so is limited to 10 seconds after the app transitions to the background. You can extend this to 180 seconds upon request, or indefinitely if you put background location mode in your Info.plist.
Read more here: http://www.davidgyoungtech.com/2014/11/13/extending-background-ranging-on-ios
Related
I am building an app that require me to continuously save iBeacons that match my uuid that are near by. I have used region monitoring, and region ranging when within region. When I do this in the background, it seem to take up about 7% of the battery every hour.
Any thoughts on making this efficient? is there a different way to do this instead of using CoreLocation?
I would like to use iBeacon to detect the proximity to a hardware (emitting iBeacon signals) when the app runs in background.
Is there a way to get CLLocationManager to detect the location/proximity to an iBeacon whilst the app is running in background?
Does using iBeacon affect the iOS battery performance in a variable way depending on the transmission frequency of the iBeacon hardware? In other words, if we have an iBeacon that has a high transmission frequency will the iOS device drain more battery as it will be receiving more signal than when using an iBeacon with a lower transmission frequency?
Technically, it's possible to force ranging (estimating proximity) in the background on iOS. The problem is, that it has big impact on battery and potential user privacy implications, so it's unlikely that Apple would accept such an app into the App Store.
The proper (as in recommended by Apple) way for an app to interact with beacons in the background, is with region monitoring: simply detecting whether the user is in range of a beacon. If you want to force background ranging though, there's a short guide for that: https://community.estimote.com/hc/en-us/articles/203914068-Is-it-possible-to-use-beacon-ranging-in-the-background-
Cheers.
There are two different ways to use iBeacons - checking for region changes, or checking proximity to beacons.
In the background, you can't poll a beacon for proximity directly, you must instead use startMonitoringForRegion: to monitor for the crossing of the region boundary. Once that boundary is detected, your app will wake up to process in the background and handle what you want it to handle.
The application:didFinishLaunchingWithOptions: dictionary contains a key that indicates your app was launched due to a location event.
The transmission frequency of the beacon only affects the battery life of the beacon.
I am developing an application which will have multiple ibeacons to detect and react according. The client has different stores in which he wants to deploy the beacons. I am now in a situation where the ibeacons are very close to each other. All the beacons share the same UUID but different major and minor values.
The situation is this:
A user enters the shop and it receive first notification through beacon monitoring. Now to get the other notification for the other beacon the user has to left the region and enter it again in order for the didEnterRegion to call otherwise the user will not get the alert for the other beacons. And that is not happening in my case. The beacons are close to each other that the user not really leaves the region once it enters it. And the notifications do not come through ranging once the device is locked or the application is killed.
Any suggestions on how to tackle this problem in a real case scenario. How to get the notification for all the beacons on a lock screen. I am using the estimote beacons for development.
This is a common problem. As you have seen, background detection is only triggered by region monitoring, and if your regions are set up to cover multiple beacons in the same physical area, you won't get background notifications as you move between them.
You can only get entry/exit updates in the background for a maximum of 20 BeaconRegions per app. So the common solution is to creatively use these 20 BeaconRegions for maximum results. If you have 20 or fewer different beacons within range of each other, the technique is straightforward -- you simply create one region for each beacon, and monitor on all of these.
If you need to work with > 20 beacons, then you have to come up with a numbering scheme that helps this along. For example, you can set all of the beacons' ProximityUUIDs to the same value, number your major values 1-20, and then set the minor values to a unique number for each beacon. You then would then monitor for the 20 regions, each with a different major number. You would also set up simultaneous ranging so you can also get the minor identifier of detected beacons. Like this:
CLBeaconRegion *region1 = [[CLBeaconRegion alloc] initWithProximityUUID:uuid identifier:#"region1" major:1 ];
CLBeaconRegion *region2 = [[CLBeaconRegion alloc] initWithProximityUUID:uuid identifier:#"region2" major:2 ];
...
CLBeaconRegion *region20 = [[CLBeaconRegion alloc] initWithProximityUUID:uuid identifier:#"region20" major:20 ];
[locationManager startMonitoringBeaconsInRegion:region1];
[locationManager startRangingBeaconsInRegion:region1];
[locationManager startMonitoringBeaconsInRegion:region2];
[locationManager startRangingBeaconsInRegion:region2];
...
[locationManager startMonitoringBeaconsInRegion:region20];
[locationManager startRangingBeaconsInRegion:region20];
This technique works well if you can ensure that there is never a case where two beacons with the same minor number that would be within radio range of a mobile device simultaneously (e.g. beacons with the same minor must be > 100 meters apart). If you can't do this, then you have to start making compromises.
Multiple beacons monitoring is not possible. Since iOS has limits, maximum number of supported regions should be 20. We can achieve your use case by doing the followings.
Group all the beacons with single UUID. We can monitor one region instead monitoring multiple regions
Capture the nearby beacons through ranging(Monitoring will trigger only enter and exit. When the user stays within the region for longer time, then monitoring delegated won't be triggered.) Sort the beacons with proximity received through didRange method.
If no beacons found with "Immediate" Proximity, move to next proximity Near.
Display notification if we found any one beacon with proximity Immediate. If more than one beacons are found with immediate proximity, then sort using RSSI. Lowest RSSI will be the closest beacon and display the notification for the closest one.
If no beacons found with "Near" Proximity, move to next proximity Far.
Display notification if we found any one beacon with proximity Near. If more than one beacons are found with near proximity, then sort using RSSI. Lowest RSSI will be the nearest beacon and display the notification for the nearest one.
If no beacons found with "Far" Proximity, then you don't have any beacons nearby.
Display notification if we found any one beacon with proximity Far. If more than one beacons are found with Far proximity, then sort using RSSI. Lowest RSSI will be the nearest beacon and display the notification for the nearest one.
Unknown - You can ignore this
You can approach this problem and solve it way easier. Stop triggering the notification when the users exit the region. Use instead the proximity function which will give you more flexibility: use CLProximity. You can choose between immediate, close, far etc. So based on the minor of the beacons and its proximity you can trigger the notifications you want.
I'm trying to understand how you are supposed to detect proximity changes in the background.
The only window I get to range is when I enter a region, but this might be pretty far away.
I would like to present something when the user enters "near" or "immidiate", but if you get "didEnterRegion" at far, than stand around, then approach the beacon, you don't get any more ranging time, because you are still in the same region.
Is there a way to either extend the "ranging" time to let the user get near the beacon, or can you make "enterRegion" happen at a different proximity than "far"?
Background ranging time is limited to a few seconds as Charles says in his answer.
If you need to delay action until you are in the immediate region, then you must use iBeacons that allow you to reduce the transmit power so the transmission radius is smaller. The RadBeacon product from RadiusNetworks has this configurability for this exact purpose.
If you configure a RadBeacon for minimum transmit power, your phone will not detect it until it is a few feet away, sending you the entry event and starting your limited ranging window at that time.
Full disclosure: I am Chief Engineer for Radius Networks.
This walkthrough shows how to do what you're asking. I'm in the process of adapting and testing it for iOS 8, but the resulting app works well on iOS 7, pushing local notifications whenever the proximity changes.
In the best practices section in Apple's Getting Started with iBeacon guide it mentions that ranging API should not be used in the background.
• Ranging API are not expected to be used in the background. For best results, ranging should
be used when your app is frontmost and the user is interacting with your app.
Could be a shortcut to app rejection, so take caution.
Given this, you shouldn't really be expected to determine proximity when in the background. I'm also employing the low signal technique, but it becomes a little trickier to differentiate between beacons when you only use one monitored region for multiple beacons...
What's possible with iBeacons in background is pretty limited.
What you can do is monitor regions in the background (which gives you the didEnter / didExitRegion events).
You can also switch on ranging for the beacon and, for the 10 or so seconds after you get a beacon enter / exit event from region monitoring you will also get ranging info (i.e. the immediate / near / far data).
Perhaps you could trigger a local notification at that point to try to get the user to bring your app into foreground - then you'd be able to get the ranging data. If not then, based on my tests, you're only going to get the 10 seconds of ranging data.
To your question about adjusting the ranging time or adjusting the enterRegion proximity - no, these aren't possible in the current version of iOS.
I have been playing around with various test apps that detect when the device enters or leaves the iBeacon's region but my question is are there any apps that will detect when a beacon is turned on?
The reason I ask is that if I sit in the same room as my iPhone and remove the battery from the beacon then re-insert it the none of the apps that I have tried so far trigger a region entered response.
Please excuse my non tech question as until I can find out if this type of detection is possible I haven't yet fully immersed myself in the coding as it may not be suitable for my application.
Think about it from your phone's perspective: Powering down an iBeacon looks exactly the same as moving out of its transmitter range. Likewise powering up an iBeacon looks exactly the same as entering its transmitter range.
The way that the iOS CoreLocation monitoring callbacks work (didEnterRegion / didExitRegion) is exactly the same for the two cases above.
I suspect the reason you aren't seeing a didEnterRegion callback when you power on your iBeacon is because you didn't leave it unpowered long enough. It takes time for iOS CoreLocation to decide the phone exited a region, and it generally won't tell you that you entered a region if it thinks it never left it.
Two suggestions to make this easier for you.
When doing testing like this, always verify you get a didExitRegion indication before expecting a didEnterRegion event. (Add NSLog lines to your appDelegate to help you see this.)
Turn on ranging for iBeacons whenever you set up monitoring for iBeacons. This makes the time needed to detect region transitions much faster when you are in the foreground.
More information on the time it takes to detect region transitions can be found in this blog post.
I had similar experiences and assume the phone checks for new beacon only when you move around. That makes sense from an energy saving perspective and the main use case of beacons.
To detect a beacon when it's powered on is possible, if the CLLocationManager object is currently ranging for the beacon, and it's already in range.
The thing to understand here is the difference between region monitoring and beacon ranging.
Some apps only start with region monitoring, ranging only when a region is entered, and stop ranging when the region is exited.(taking the batteries out will cause the region to be exited) When you put the batteries back in, the beacon in this case is not detected because ranging has been stopped.
When your app launches start ranging with startRangingBeaconsInRegion: method and don't stop this anywhere in your code.