I'm trying to send a notification through my iOS and Android apps when a user walks through the front door of a restaurant. I've tried Geofencing, but the minimum radius isn't small enough and people will get notifications from multiple restaurants in the area. I know iBeacons exist. Are they my only option? (I know Foursquare sends these kinds of notifications, but I don't think they use iBeacons.)
Beacons are much more accurate than Geofences, but they still have a range of about 40 meters. In a dense urban area, beacons might still trigger notifications from multiple adjacent restaurants at the same time. You might also trigger the notification as the user walks by on the sidewalk. There are ways you can lesson the likelihood of this by placing beacons inside the restaurant so the signal is very weak outside. But you cannot eliminate it.
The Foursquare does use beacons. I know this because the Android version of their started being bundled with the Android Beacon Library about two years ago, and I'm the lead developer on that open source project. That said, I suspect they use a combination of geofences and beacons, only using beacons for cases where customers actually have them installed.
Geofence-based notifications are especially problematic on iOS because geofences often fall back to location from cell towers to save battery when no location apps are in the foreground. Cell tower locations are only accurate within a kilometer or two, and will trip a geofence of the outer range of the location uncertainty overlaps with the geofence. This can trigger a restaurant welcome notification from over a mile away.
One way to improve bad Geofence-based notifications like this is to use the following technique on iOS:
Request an extra 180 seconds of background running time when the geofence is tripped.
Request location updates with GPS, and monitor these updates for 180 seconds in the background.
Using the location update data, if you find that the accuracy of the fix is high enough and the distance from the restaurant is small enough, then trigger the notification. Until and unless this happens, don't trigger it at all.
You would need a beacon inside the restaurant already, otherwise geofencing is going to be your only option. You could combine geofencing with a gps call and see if the gps call is within a lat long you have deemed to be inside that establishment, and then repeat this gps call every few minutes while you are inside the geofence until it matches a coordinate inside the place.
The disadvantage to this approach is that the battery drain will be higher than using ibeacons, which operate using BLE (bluetooth low energy)
Related
i'm creating a location tracking app to let users plot a heat map of where they traveled throughout the day. this involves constantly gps querying the user's location, a battery-intensive operation. one way i thought to reduce the app's power consumption is to set up a geofence after a few location updates return roughly the same value, and shutting down the location updates until the user exits the geofence (signifying that they are once again on the move).
this will allow my app to only perform frequent GPS queries when the user is actually moving (triggered by them exiting a geofence).
however, i'm not quite sure if this will reduce power consumption, because if the geofence is triggered by constantly querying the user's location to see if they have moved outside the fence, it will have basically the same effect on the battery.
so my question is, how does the geofence know when the user has left/entered the area? is it based on simple periodic location queries? or is there some more clever mechanism involved? thanks!
link to current version of app:
https://play.google.com/store/apps/details?id=com.russ.locationalarm&hl=en
The way Android is handling geofencing is quite complex. There are many differences between devices, but also between Android versions. But as a quick answer, your solution could save battery, because detecting a zone exit don't necessarily require GPS, but could use other location methods like Cell ID or Wifi, which are much less battery consuming. You also need to know that geofencing is not a 100% reliability solution, in particularly on Zone Exit events (less than 50% of zone exits detected in average), that are less reliable than Zone Enter events. Some companies like Herow, Radar, Foursquare are building SDKs that manage specifically geofencing.
There may be similar questions regarding this topic,But I need your thoughts and suggestions on some specific requirement.
Here is my need -
We are developing one app which tracks User's trip.
The app will start collecting the location of that user in background,When user 'Starts' his trip from App.Background Service will be fetching locations on the basis of user's movement in specific time duration.
When User 'Stops' his trip from App,We are calculating distance traveled by user with help of all recorded locations(With Google Distance calculating API).
The App works fine in ideal case.
But main challenge is -
In some scenarios,We are not able to fetch exact and precise location of User. Scenarios affecting is - No internet,Data plan with 2g/3g,some specific areas where GPS is not returning accurate data etc.
Incorrect data of lat-long causes incorrect Trip distance and route.Which is main problem with the App.
Please,any one can suggest the best alternative/Suggestion for this?
P.S. - We have tried GPS,Network,FusedLocationProvider.
EDIT 2 --
We have implemented logic on basis of accuracy and distances.Got nearer points. And just came across one useful api from Google that corrects some location points which are distracted from actual Roads. Posting here for reference of others...
Snap to Roads Api from Google
this is a complicated topic.
One consideration you have to take. Android Oreo limits background services and that what you want to achieve won't work.
I would do is this (and it is the recommendation from Google)
When someone starts the trip (the user is aware of it), you must launch a on going notification with a foreground service , don't rely on background services anymore. Check the feature "Start Activity" in Google Fit App.
As for not having signal, or accurate GPS, well... it is a geographical problem!, there is nothing you could do. Or, maybe you can, using the LocationProvider.
FusedLocationProvider is fused within every app that requests locations updates.
Read this out, and see if that helps you.
https://developer.android.com/guide/topics/location/strategies.html
Try to mix GPS and Accelerometer
If you detect that GPS stopped working, turn on accelerometer. If GPS is turned on again, calculate distance again with it. This way you can have route with GPS parts and accelerometer ones. The bigger GPS parts, the more accurate data will be
How to get more accuracy by GPS_PROVIDER
Basically if the accuracy of a location isn't acceptable throw it away. The next one will be better.
I have a theoretical question. I want to track a user with my app (iOS and Android) in order to notify him at a given time (11:45am) and just if he is next to a specific location (with lat/lng) even when the app is not open.
Is it better to check the users location every 5 minutes when the device tracks a 500m change, and make a request to the server (if the time is right, and if the location is right), and then send out a push notification (when location and time is right)? Or should I send out a transparent push notification (without a visual notification) in order to wake up the app and to check the current location of the user? Is this a common practice?
EDIT I think the question is not as clear as I thought it will be, so I want to be more precise: I want to notify my user (iOS and Android) if they are at a specific location (specified with lat/lng) at a given time (e.g.: 11:00am), even when the app is closed.
How can I do that?
Your 500m requirement is inbetween GPS and cell tower.
cell tower locationing has about 1000m acuracy in cities and up to 3km in rural regions, this location technique is used in geofencing and the ios auto-wakeup (your "when the app is not open") is used. This does not need much battery.
GPS has about 3-20m, accuracy and uses more battery. battery consumption does not change wheter you check every second, or let the APi call you every 100m. Some highest acuracy mode ios (mode best_for navigation), addionally enable acceleration sensor, whigh might need a bit more power then. (This mode, you dont need)
(In cities also the Wlan location technique may provide a location probbaly meeting your req.)
So you have the choice between 1000m low battery or 5m high battery consumption.
There is nothing inbetween (besides sometimes WLAN).
I have an app which will take some (internet) action every time the user approaches any one of a set of locations (for example, let's say it notifies a server whenever I am near a Starbucks shop, so my coffee habits can be analysed).
What's the most battery-efficient (yet reliable and relatively accurate) way of causing the phone to do something whenever it's at a certain location? I don't need perfect location accuracy - within 50m or so is fine.
Currently, I set a ProximityAlert for each location with a 100m radius, and have it raise an Intent, which is then served by a Service which runs in the background. The service also includes an Alarm which causes a download every three hours or so.
The Service itself doesn't appear to drain any significant amount of battery - the battery is all drained by "Android OS". According to the Android 4.1.2 Battery monitor, Android OS is using 3x as much CPU as a phone without my app, and has "stay awake" on for most of the time.
Would changing it to an IntentService make a difference?
Would reducing (or increasing) the radius of the alert make a difference?
Would converting it to a Geofence (https://developer.android.com/training/location/geofencing.html) make much difference?
Can I set it to use a cheaper location service unless it thinks it's close to one of the locations (or will it do that automatically?)
I have never worked with the LocationManagers proximity alert functions, so I do not really know how much they drain the battery, but as far I know the new Geofence services (https://developer.android.com/training/location/geofencing.html) were specially designed in a battery-friendly fashion.
LocationManagers pose a very difficult way to program something that you need. Google has reinvented its location providers to fuse them with sensors. Its the latest and best, uses less battery and does magic with your application, by removing all the 1000's of lines of useless code that you need to write between your gps / network providers.
The new api's are LocationClient api's. Watch this video and demo for yourself.
you can use new geo fence api provided by the Google recently,its more power efficient
https://developer.android.com/training/location/geofencing.html
I'd like to know if this is possible on either Android or iPhone:
I would like to have an application run in the background of the phone and send a GPS location to the server every N minutes. As far as I know this is difficult on the iPhone, but can it be done on an Android?
Thinking a bit more on the iPhone - could I create a web service that runs timers for each application and, on timer elapse, push a notification to the phone to start the GPS service and send the location information back to the server? Can I push notifications to an iPhone application in the background?
Thanks!
Re Android: yes, this is also possible, and just as with the iPhone, the less accuracy you need, the faster this will be. It is also asynchronous , so you will need a similar approach. As opposed to the iPhone though, you can start the GPS and wait for location updates in a background service, so that you can send the current location to the server whenever you have it.
Re iPhone: yes, you can push notifications when the app is in the background, but you should know that the location services API is an asynchronous API (having been working on it myself...:)) so you can't time it per se (you can for example "expose" it every N seconds, saving the last location that was provided - so essentially implementing a logic that will make it asynchronous, but with a certain cost to the user experience).
Also note that having location services running in the background is a huge drain of battery. here it really depends on the type of application that you are building. If you dont need high accuracy (say, knowing the city is enough) you could set the accuracy of the API to be large, which wont trigger WiFi and GPS, and will use only cell - less battery drain. If you need really high accuracy (street corner, etc.) this wont be super useful for you.
Adding some more info for your convenience: like I mentioned, accuracy requirement will trigger the different location services, which in return affect batter consumption. In general the accuracy is:
GPS: ~10 meters
WiFi: ~100 meters
Cell: 500 meters (urban canyon environment) to 50Km (in open environment)
Hope that helps.