The number of questions on SO related to iBeacon and its background capabilities is increasing and there is some confusion on that point.
I have been testing the AirLocate project.
iBeacon has 2 "capabilities": Region monitoring and Ranging.
Region monitoring is limited to 20 regions and can function in the background (of the listening device) and has different delegates to notify listening app (and user) of entry/exit in the region - even if app is in the background or phone is locked.
Ranging works only in the foreground but will return (to the listening device) an array (unlimited?) of all iBeacons found along with their properties (UUID, etc..)
In addition, that 20 regions monitoring is a device limit. If the user is using geofencing reminders, other apps that use region monitoring; this will lower that number.
So are we saying that I can not deploy a mall-wide (100 stores+) app that uses store iBeacons to send a "store specific" notification to the user, while the app is in the background or the phone is locked?
I gather that the advertising device (the beacon) has to be in the foreground as well to advertise a region that the listening device could "enter" into. So are we saying, that if the owner of a store had an iOS device; I could not for example save him money by asking him to use his iPhone (at least early on) as an advertising device (beacon) - since the app will likely not always be in the foreground?
So in the case of iBeacon + MLB, a single UUID (or <20 UUIDs) is/are used for the app to possibly determine entry door and, then will the user be required to unlock the phone/bring the app to the foreground to use it (find seat, etc..)?
Can I then call the iBeacon: a single location/event (store, park, etc..) feature that requires the user's most "foreground" attention to have a "complete" practical use case?
I have tried to be articulate about the user cases to bring it to practical. Please reply with more than yes or no.
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…