Using the estimote beacons, I get multiple local notifications fired from didEnterRegion. I only range & monitor 1 region under which all my beacons reside.
I am trying to restrict this functionality so that users only get notified once whilst in the region. I would think this is out-of-the-box functionality since there's a corresponding didExitRegion event, so in essence you only get 1 notification whilst inside the region.
I don't see this behaviour though. Event didEnterRegion fires multiple times while I am physically inside the region. So I implemented a counter that's initially set to 0 and increments by 1 every time I'm inside didEnterRegion. I only allow the local notification to fire when the counter < 1.
But this has left me wondering; how will this work when the app is not running? Also, by doing it this way (i.e. not resetting the counter back to 0 via didExitRegion) do I only notify the user just once throughout the presence of the app on his phone, regardless the times he will physically enter / exit the region (while the app is installed and not running)? I want to inform him just once whilst in the region, and not just once in general.
I'm clearly confused with this, so would love to hear any feedback.
Make sure that you're not monitoring the same beacon multiple times, by inspecting the monitoredRegions property of your ESTBeaconManager/CLLocationManager.
Related
I want to use the new Geofence API of iOS 8 (scheduleLocalNotification:).
I schedule a UILocalNotification with a region and so on. Everything works, but how can I differentiate between ENTERING and EXITING a region, resp. ignore EXITING?
iOS always displays/sends a notification, but I only want a notification when the user enters the region.
Right now I think I have to stick to the "old" startMonitoringForRegion: API.
Is that correct?
You can set region.notifyOnExit = NO to only receive notifications when you enter a region. You can also set region.notifyOnEntry = NO to only receive notifications when you exit a region.
If you want to monitor both, while still being able to tell if it is an entry or an exit, I see two options. The first option would be to schedule two notifications, one where notifyOnExit is false and one where notifyOnEntry is false. The second option is to use the existing startMonitoringForRegion api to monitor both. It depends on the use case.
Keep in mind that there is a limit to the number of regions that can be monitored (currently 20 per application I believe). I'm not sure if monitoring the same region twice counts as one or two in this case.
Hope this helps.
For a specific business case, I would like to trigger proximity-based notification (push or UILocalNotification) by leveraging the iBeacon technology.
This is aimed to work while the app is in background/lockscreen.
I have some specific constraints :
The product has to scale at a certain level so it's not possible to range 20 regions. We will range on one UUID only (maybe 2 or 3 if we develop new set of features, but we will not register a region per physical beacon)
We will use the major and minor to call webservices
Regarding this, I know I will have to use the following approach : first didEnterRegion: with no prior information on the major/minor/distance, and then didRangeBeacon: to perform more advanced actions.
I already use local storage mechanisms to timeout a beacon after he has been used considering the fast beaming rate of beacons.
* The major constraints : we have to region events regarding to the distance of the beacon (exemple, only trigger the notification if CLProximityImmediate)
Now I see a major limitation. As my app will only range in background for a few seconds after it entered in a region, if I had constraints based on the distance/proximity, it is very possible that the app will:
return to background state before the user get close enough from the physical beacon for the event to be triggered
never be triggered again because it has to enter the region to range again, which will probably not happen
Do you have any ideas / work around for such a case ?
You are absolutely correct on the limitations CoreLocation applies in this use case. If you set it up as you describe, the typical behavior will be that the app will detect the beacon in the background at an unknown distance (often the max range of around 50 meters), range in the background for about 5 secs, then the app will be suspended by iOS. That five seconds of ranging time will typically not be enough for the user to get near enough to the beacon to trigger your use case.
Unfortunately, there are no easy workarounds with standard beacons and CoreLocation. CLBeaconRegion objects do not have a distance field like CLCircularRegion does for geofences.
Two more extreme approaches you might try:
Turn off monitoring of your one region as soon as you detect the device is too far away, then re-enable it right as your app suspends itself in the applicationWillResignActive: callback. You might get a new entry event and more background ranging time.
Use nonstandard beacons that periodically stop their transmissions to trigger forced exit/entry events.
Here is our scenario:
We plan to setup around 4 beacons in huge room (i.e. like a department store). Once the user goes in the room, the application will notify the user, "Welcome to our shop!". When the user leaves the room, the application will then notify the user, "Please come again!".
The reason why we plan to place 4 beacons is that to make sure that while the beacons are in range with the device, we can make sure that the user is really still in the room. (Our worry is the user might still be in the room and the notification for saying "Please come again!" appears.)
We would like to know if it is possible to code that if the mobile device could not scan for all the beacons, the user has already left the regions and the device will send a local notification.
In order for this to work you need to:
Make sure you have full coverage of the store with the radio range of your beacons.
Set the identifiers on the beacons so they share a ProximityUUID.
Define a region that matches all the beacons (e.g. the region should define the ProximityUUID and leave the major and minor null).
Monitor for this region.
In the didExitRegion callback, start a three second timer that only sends the exit notification if you do not get a didEnterRegion callback in this period. This is needed because iOS sometimes sends a spurious exit event followed by an enter event a second later.
If the timer goes off without an enter event, only then send the exit local notification.
I'm working with a sample app for iBeacon region monitoring functionality. The Issue(not sure if it is) that I was unable to resolve is "didEnterRegion:" fires continuously for more than 2 times when I enter the region. This happens to send the local notification more than once or the times that this method fires when the app is in minimized mode.
Can anybody tell me how to resolve this.
Thanks,
It is common for a glitch in iOS to cause a didExitRegion event followed within a second by a didEnterRegion event. You can filter these out in your code by storing in an NSDate variable the time you last exited the region. When you get a didEnterRegion callback, you simply ignore it if the exit timestamp was within the last few secs.
If you are really getting these continuously as you say, something else is wrong that you may need to fix. It is possible that your iBeacon is not transmitting at least once every three seconds. This would cause constant exit/entry callbacks.
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.