This solves problems with persisted regions discussed in #1075.
Problems prior to this change:
If you start monitoring a region and then change your app code to use a new Region uniqueId without stopping monitoring that old Region, the old Region is orphaned in library persistence and continues to be monitored forever.
If you range a region, then change your app code to update the Region's identifiers but don't change the uniqueId, the old identifiers continue to be used.
This change fixes both problems.
A few notes on how Monitored region persistence changes with this update:
Immediately after starting the app, if you call beaconManager.getMonitoredRegions() before starting monitoring, you will get an empty list. You will not get the persisted list of regions. (Prior to this change you did get the persisted list of regions registered as of prior app executions, but this was really a bug not intended library behavior.)
Any previously persisted monitored regions are retained until the end of the first scan cycle, at which time they are purged unless you have called a startMonitoring... method variant for that region. If you make such a call, the region will not be purged. If you fail to call startMonitoring... for a region before the end of the first scan cycle, it will be purged, and all previously tracked region state information will be lost.
No didExitRegion or didDetermineState callbacks will be issued for "outside" Regions that are not re-registered by the end of the scan cycle.
You may still get a didEnterRegion or didDetermineState callback for a stale previously registered region that has not yet been purged. This should be a very rare event and would only happen once if a matching beacon is detected on app launch with a stale persisted region before the end of the very first scan cycle on app launch.
This solves problems with persisted regions discussed in #1075.
Problems prior to this change:
If you start monitoring a region and then change your app code to use a new Region uniqueId without stopping monitoring that old Region, the old Region is orphaned in library persistence and continues to be monitored forever.
If you range a region, then change your app code to update the Region's identifiers but don't change the uniqueId, the old identifiers continue to be used.
This change fixes both problems.
A few notes on how Monitored region persistence changes with this update:
Immediately after starting the app, if you call
beaconManager.getMonitoredRegions()before starting monitoring, you will get an empty list. You will not get the persisted list of regions. (Prior to this change you did get the persisted list of regions registered as of prior app executions, but this was really a bug not intended library behavior.)Any previously persisted monitored regions are retained until the end of the first scan cycle, at which time they are purged unless you have called a
startMonitoring...method variant for that region. If you make such a call, the region will not be purged. If you fail to callstartMonitoring...for a region before the end of the first scan cycle, it will be purged, and all previously tracked region state information will be lost.No
didExitRegionordidDetermineStatecallbacks will be issued for "outside" Regions that are not re-registered by the end of the scan cycle.You may still get a
didEnterRegionordidDetermineStatecallback for a stale previously registered region that has not yet been purged. This should be a very rare event and would only happen once if a matching beacon is detected on app launch with a stale persisted region before the end of the very first scan cycle on app launch.