We are currently using the new Proximity SDK for Android. We are leveraging the foreground notification ability to keep the app persistent in the background. We have intentionally removed the onDestroy stuff to stop it from running, because we need the app to always be running in the background.
We are currently encountering a problem where when the app is started, it creates the zones and starts observing. When we kill the app, it continues observing. This is expected and desired behavior.
However when we reopen the app, it recreates the zones and starts observing again. We now receive 2 ingress and egress events (as far as I can tell, both zones/observers are running and sending the events at the same time). If the process is repeated (kill and reopen the app) a third set of events is fired. And so on.
Everytime the app restarts it recreates the zones/observer.
We’re trying to determine how to get the app to reconnect to its previous observer or failing that, checking that the zones already exist and not recreate them.
Any assistance here would be appreciated.
First of all, make sure you won’t reduce your app UX with a sticky notification. Some casual users might not know about the possibility to call “force kill” from app settings, and they may be very angry about the everlasting notification.
As for your problem - it needs a simple clarification first. Foreground service is an app component that will keep your app process (JVM) running even when the user has destroyed all its views (activities). So from the system point of view, your app is still running. Ok, knowing this fact, we can tackle your problem in the three ways:
Create a singleton instance (will be held statically in your app’s JVM process), and start there your
ProximityObserver. The drawback of this method is that you will need to start it manually somewhere in one of your activities (and pass the
Create your own class that extends Android’s
Application class and start
ProximityObserver in the
onCreate() method. You will need to register this class in your AndroidManifest as a main
Application class. This class is loaded statically (just like a singleton), but you don’t need to start the observation from somewhere else (plus you already got the
context). Read more here
Think about your scan use case - maybe our recently added experimental feature will work nice for you. It’s called
ProximityTrigger and will display your notification whenever the user enters the range of Estimote beacons (soon be restricted to only yours). Read more here, or check the feature out in our example app. Oh, and by the way - it only works on Android 8.0+ devices.
You may also store scan handlers somewhere outside
Application class or in singleton object) and when new scan is started in
onCreate then stop previous scans.