Posts

Post not yet marked as solved
0 Replies
697 Views
Hi developers! I have been working on a smart door app project where iPhone must detect iBeacon enabled smart door lock our company provide. The base scenario is that when a user with our app approaches our door lock, the door lock measures the approximate distance. Once the user gets close enough, the door lock advertise iBeacon packets. Then, regardless of the state of our app whether background, foreground, suspended, or terminated, our app should go through BLE communication with Core Bluetooth. In almost all cases, our app seems to behave fine. If the app has been terminated, iOS automatically launches our app in the background and our logic can handle door opening process. Thanks to the region monitoring in CoreLocation and state preservation and restoration in CoreBluetooth. However, once every few days, didEnterRegion stops firing which is responsible for background launch and initiating the door opening logic. When this happens, throughout some debugging, we have found some interesting remarks. Our door lock does advertise iBeacon packets correctly because other scanner app within the same iPhone detects the door lock. So it is not that iPhone doesn't receive the iBeacon packet. While our door lock advertises the iBeacon packets, and our app is not receiving the "didEnterRegion" event call in the background, if the user put the app in the foreground, it starts receiving "didEnterRegion" again. Likewise, just like No. 2, While our door lock advertises the iBeacon packets, and our app is not receiving the "didEnterRegion" event call in the background, instead of putting the app in the foreground, if the user goes to "Settings app" -> "Bluetooth" and wait for 2~3 seconds, iOS sends "didEnterRegion" event if the app has been in background, or launches our app in the background if the app has been terminated. The problem described in No. 2 and No. 3 is more likely to occur if there has been an error didFailWithError Error Domain=kCLErrorDomain Code=0 "(null)" So the real question in a nutshell is, in case of No. 3, why putting the app in the bluetooth menu in Settings app fixes this issue? What might be the cause of this issue? Is it definitely-my-code problem? If so, how can I tackle this instead of letting the user actively put our app in the foreground or asking user to stay in the bluetooth menu for few seconds? Any of your opinions, thoughts, or facts are highly appreciated. Thanks,
Posted Last updated
.