We found there’s a behaviour where enter region is not triggered with estimote beacon on ios 7.1 and also other higher version is that, enter region is not triggered when the device is in range with beacon during first installation into the app.
Sequence to simulate the behaviour
- Near to a beacon
- Install app with beacon monitor
- turn on bluetooth
- No enter region is triggered
Beacon os is latest version while broadcasting interval and power strength is the default value, the only changes is UUID is updated.
Do you have any clue on this ?
Unfortunately, you need to run the app at least once, so that it registers the monitored regions (via the startMonitoringForRegion
method).
Sorry the app is run at least once.
- Near to a beacon
- Install app with beacon monitor
- Open the app
- turn on bluetooth
- No enter region is triggered
Enter will only trigger if the region changes state, i.e. if the app starts with the beacon out-of-range, and then moves in range. If you want to determine the initial state, use the didDetermineState
instead.
Example:
// App starts, beacon is in range.
didDetermineState: CLRegionStateInside
// iPhone moves out-of-range
didDetermineState: CLRegionStateOutside
didExitRegion
// iPhone moves back in range
didDetermineState: CLRegionStateInside
didEnterRegion
In your opinion do you think using didDetermineState to track the enter and exit VS didExitRegion and didEnterRegion because you dont need the change state to happen ?
I preassume we should do the same in android SDK ?
Thanks,
Depends on the use case:
Example 1: the user’s at the airport, sitting at the gate. She turns her Bluetooth on, iOS determines she’s inside the region “gate 7”, but her flight departs from gate 12, so it triggers a notification. In this case, using “didEnter” instead of “didDetermineState” would break the use case.
Example 2: you want to greet the user when entering a shopping mall. He enters the mall with his Bluetooth off, stays their for an hour, then turns the Bluetooth on. iOS will determine he’s inside the mall, but won’t trigger “didEnter” because there was no state change. If you used “didDetermineState” here, he’d receive a greeting notification despite entering the venue an hour ago.
Our Android SDK doesn’t yet have a didDetermineState equivalent I’m afraid, stay tuned for an update.
Thanks for your reply. For example 2 how would you suggest me to handle that on android ?
Example 2 relies on didEnter
, not didDetermineState
, so it’s easily doable on Android: use the monitoring listener and the startMonitoring
method of the BeaconManager.
For example 2, the person is in the zone and no state change, how would it trigger the didEnter event ?
To add on for didDetermineState, this event actually must have app running in background ? If no app is running in the background for ios case, only didEnter and didExit will happen ?
I tried the below sequence with didDetermineState
- In beacon app
- Open app for first time with bluetooth off
- Close the app
- Open bluetooth
- Nothing happen
- Put phone into standby mode with power button
- Wake up from standby mode by pressing on power button
- didDetermineState is triggered
Is it true that item 5 wont happen regardless of how long you waited ? and didDeietermine is only triggered when phone is active regardless of whether app is running in background.
I’m working on an iBeacon app and just tackled a lot of what you mentioned…
didDetermine is triggered when the app is in the background when you have background updates turned on, have requested always permission and provided the always usage description in your info.plist.
Regarding didDetermineState vs. didEnter/didExit, in the app I’m working I’m using didDetermine state to get the initial state, but at the end of it I’m calling startMonitoringRegion so I can then get didEnter/didExit callbacks.
Hope that helps!
1 Like