The answer in absolutely yes, BUT… Read on to get the full walkthrough of geofencing in the background
This a topic that we discuss very often with developers and marketers. How can I create a geofencing campaign that will be able to push a notification in the background? This blog post will cover the whole issue, as clearly as possible. This is the geofencing-for-dummies version. If you don’t want the whole babble, skip to the summary.
This post was updated 2nd May 2018.
Key terms
In case you are not familiar with some of the terms above mean, let’s start with defining the key words here:
Geofencing: Ability to define areas in the physical world, where you want your application users to receive a message, when they arrive at a specific place. This could be an advertising, or a piece of information. For example, you would want to notify your Starchunks app users, when they are near your coffee shop. The word “fence” is a good description of their functionality. You build the fence digitally around the area on the map by drawing. When your customers walk inside the fenced area, the app will be able to detect the fence, and send them a notification.
Geofencing does not have to be connected to marketing. You can also use it just for counting, how many times your customers walk by your store. And, very importantly, with Proximi.io platform you will be able to use geofences also indoors and for defining much smaller areas, e.g. detecting when someone enters the milk shelf in your grocery store.
Push notification:
Push notification is a short message, that an app may send to you, when there is some new information or content that is relevant to you. For example, when you receive a new Whatsapp message, you will receive a notification from Whatsapp app. You can also use these to notify that in the area, where your app user is right now, there is something interesting for them. Clicking the notification will typically open a relevant view in the app.
Background: Background refers to situations, when your app is not actively in use. For example, when you are browsing Facebook, you are using in in the foreground. But when you switch to another app – or when you are not using your phone at all, Facebook goes into background mode. The technical details of how that transition happens, depends on the phone model. For example on iOS, part of the background mode is called “suspended mode”. In order of clarity, we will summarize these different modes of “app not being used” as background. If you want to be able to send a notification to your app users, even if they are not at that exact moment browsing it, you need a geofencing solution that has background support.
Application: We are very specifically talking about mobile applications. At the moment, there are no options for pushing a notification through a website, when the website is not actively in use.
The walkthrough of background geofencing
To understand background functionality, it is good to understand first, why applications to go background mode. This is simply to free up memory, and to minimize battery drainage through clearing up the apps that you are not needing at the moment. Those apps will go to sleeping mode, from which they will be able to wake up, when needed.
In order to detect a geofence, the app needs to know the phone’s position. As a standard, it is not keeping track of the position all the time, as that would have a dramatic impact on the battery life. Typically they only access your location, when you are actively using the application. When the app goes into background mode, you need to wake up the app every now and then to sniff the mobile phone’s position. Naturally, the more often it would sniff, the faster and more reliably it would be able to detect the geofence. But, if the app would be constantly requesting for the phone’s position information, you could end up having really unhappy application users with drained batteries. Therefore the operation system manufacturers have built their own limitations to how the requesting happens in the background.
Android:
Android gives you as a developer a good range of options on how to utilize location in your app. For native positioning – that means the GPS, WiFi and cellular data that Google Location API is taking into account for determining your position as a standard – you have the option to define how accurate you would want the information to be. Cellular has the least effect on the battery, and only utilizes the location deducted from the information of the nearby cellular towers, but also results in poor accuracy. Wifi utilizes both cellular and Wifi information, and has a good balance between accuracy and battery-efficiency. It is in most cases the optimal option. GPS utilizes in addition to the two previously mentioned also the direct GPS information from satellites. It is very accurate, but consumes a lot of battery.
How these technologies are utilized in the background, changed drastically in Android 8 (see Google dcoumentation). These limitations apply to all apps used on devices running Android 8.0 (API level 26) or higher, regardless of an app’s target SDK version. Whereas in the previous Android versions an app could request newest location information in the background from the Google API as often as it wanted, Google API by default only refreshes location information now only a few times per hour. So even if an application did poll the information more frequently, fresh data is coming to the Location Services only at that interval.
There are a couple of exceptions to this:
- You make a foreground service in your application. A foreground service is meant for running on-visible tasks in the application, when user is not using the application. Foreground services must show a status bar notification, in order to make sure the phone user is aware of the task taking place. Depending on your application, this may be something that the user is not too bothered about, but in other cases it may be considered as annoying. Example notification on the right. Note that this is a notification that cannot be swiped away. When a foreground service is used, frech location information is available on WiFi and cellular levels every 60 seconds, and on GPS level every 10 seconds.
- When another application in your phone that uses native location is used in the foreground, the refreshed location information in Google Location API is also available to other applications.
Regarding Bluetooth beacons that can be used for micro-level positioning (more information here), you have the option to specify, how often and when your app will be scanning for them. This applies for both iBeacons and Eddystone beacons. In the Proximi.io platform, the scanning frequency is automatically handled by our SDK. When the phone detects any beacons that have been added to our platform under your account, the phone is scanning beacons as often as it can, determining a new position every 2-4 seconds. If there are no known beacons nearby, the scanning will be done less frequently. Note: From Android 6 onwards the doze functionality will affect how often your phone will be able to detect Bluetooth beacons (see Google documentation). Doze affects your application’s performance only when the phone is completely set aside. As soon as the user wakes the device by moving it, turning on the screen, or connecting a charger, the system exits Doze and all apps return to normal activity. Another way to avoid the Doze limitation is a foreground service, as described above.
Regarding IndoorAtlas, a geomagnetic positioning technology also supported by Proximi.io (more information here), the background support is not unfortunately as good at the moment. In order to determine your position, IndoorAtlas utilizes your phone’s accelerometers, gyroscope and compass, in connection to a step counting algorithm. In the background mode, IndoorAtlas is not able to utilize their step counting algorithms, and the positioning is done mainly with WiFi information. The accuracy in such situations can be only around 20-30 metres, so it should not be used in situations, where accurate, reliable background geofencing is needed.
iOS:
On iOS, there are also plenty of limitations to, how you can wake up the application from background mode. In general, your app gets no background time for requesting the position – or any other use. When you app goes to background mode, it gets around 5 seconds of background time. After that there is silence.
Therefore, you need to utilize some of iOS features that do give you some tools for it. You can for example use iOS significant-location-change feature. The downside of those is that you need to physically move quite long distances in order to receive a “significant change”. The length of that distance depend on how fast you are moving, what type of area it is etc, but we are talking typically at least a couple of blocks. You can also request for extended background time (around 3 minutes), when your app is woken app by any reason. You can use that extra time to poll for location.
Another note: Even if you were capable of creating better background support for your app in iOS, you need to keep in mind the App Store submission requirements. If you have utilized background location in a way not approved by Apple, they will not publish your app in the store. So your app will be worthless, until you fix it. For example, if you turn on the Background Location Mode in your app, it will be constantly polling for location. That is great for you, but not for the battery. Therefore Apple only permits apps that have a functional reason for that, for example navigation apps, into App Store. The Proximi.io SDK follows all the App Store regulations both on background mode and other topics.
If you would want to trigger something on a much smaller scale, iBeacons are an excellent tool for that. iOS devices have native support for iBeacons, which means that when the phone detects an iBeacon device nearby, it is able to immediately wake up your app. Important note: this only applies for iBeacon standard. iOS has no native support for Eddystone, so with Eddystone beacons you are limited to the same significant-change and random background time as mentioned previously.
Regarding IndoorAtlas, the situation is even more limited than on Android. As the iOS operating system does not allow you to scan for available WiFi access points in the background, no location data is available through IndoorAtlas in the background.
The feared iOS11 blue bar. Currently the status of whether or not a blue bar is show, when an app uses location changes with every iOS version. At the moment, by default the blue bar will not appear when you use location in the background, when the application user has given a permission for that.
Cordova/hybrid apps:
Hybrid apps have become more and more popular. Tools like Cordova are a way of building applications through a simpler language (JavaScript) and for both iOS and Android at the same time.
Regarding positioning, your hybrid apps can function exactly like native Android or iOS applications. You will be able to read all the same sensors and build the same background support for each of the technologies and operating systems. That is because Cordova is simply a way to package a native Android or iOS application faster. Proximi.io has also a Cordova plugin, that has all the same features as for native SDKs bundled together.
Summary
This table summarizes the potential of using different technologies for geofencing in the background.
| Android | iOS | Cordova | |
|---|---|---|---|
| Native location | Limited, location data available only a couple of times per hour. Exception: Foreground service | Limited to a significant location change Exception: Background location mode | Will act exactly as native Android / iOS |
| iBeacons | Yes | Yes | Will act exactly as native Android / iOS |
| Eddystone | Yes | No | Will act exactly as native Android / iOS |
| IndoorAtlas | Limited to WiFi information only, accuracy 20-30metres + | No | Will act exactly as native Android / iOS |
Keep in mind, that these are the best-case scenarios. In order to achieve this, you need to build the background support into your app. With the Proximi.io SDK you’ll get the best possible coverage for everything summarized.
Anything we didn’t cover? Leave your questions below!
Proximi.io
Hi. I am working on geofencing background. but every time i move from one location to another i will get that location but not able to do geofencing on that new location. How to add new location for geofencing ? Thank you.
Hi, if I understood your problem correctly, this tutorial of adding a new geofence might help: https://proximi.io/proximity-zero-hero-part-2-5-geofences/
Hi, I am working on Geofencing background in Android. However in Background ,i am able to get the users current location, newly added fences, updated fence but unable to get the callback of users fence enter and exit. Whenever i open up my app i got the callback of Geofence enter but it is not happening when the app is in background mode.
Hi, sorry for the late reply! I would need to know a bit more about your setup to be able to pinpoint the issue.
One potential reason could be that you are using Android 8, where the background functionality is more limited, if you have not enabled location as a foreground service. I will update this blog post to include that aspect.
Good day,
Could silent notifications perhaps be used to retrigger the geofencing functionality if the app is in the background?
Hello! Once a person enter a geofence, it creates a enter event, a trigger for us. This function also works in the background, and you have the option to trigger an action when this happens, it being a push notification or just information for you to know that a device entered a location, without sending any notifications to the user. You can also send a low-priority push that could be called a silent push.
Could you elaborate what you meant by retriggering the geofencing functionality?
Hi,
Will it work if user terminate the aplication from recent app list?
Hi,
Depends a bit on the app settings, but in some cases the SDK is capable of waking up the app in the background after the app being killed, which will again enable the functioning as normal.