I have implemented the geoFence api and everything is working good. But there are some problems, I want more clarification regarding my confusions.
Here are some of the confusions and problems:
I want my user to get notified when he enters a geofenced area. I have implemented the GeofenceTransitionsIntentService as per guideline but it is not triggering the transition when the app is in background. What should I need to do?
GeoFence Expire time: it is pretty obvious that if we enter Never it is not going to expire, but I am confused about the time. For example if I set it to 10 minutes, what does that exactly do? Will the geofence expire after the given time since it is created or it would expire when the user arrives at that place and then the timer would start? How can we get the geofence to expire when the user gets there.
How is Google tracking us? How does the geofence actually work? We are not sending our location, then now it is tracking ? Does it start tracking us when we add a geofence and then notify us when arrived at that place?
Please tell me and discuss about these confusions, especially my confusion about it working while the app is closed or destroyed.
About 1.) According to this Google I/O Talk When you're using PendingIntents the Location API should wake up your app even if it's runnning in the background, although from my experience the Geofencing events are quite unreliable, but this might be related to a bad GPS receiver in the device I used for testing.
Related
I have been exploring launching an app with no servers(just an app on android phone), but when a user reboots his phone, he loses the reminder notifications that were set previously in my app which is not opened that often as it is more a reminder app. I have this previous post that I just added a bounty too
https://stackoverflow.com/questions/63293900/code-in-trying-to-reschedule-previous-alarm-notifications-in-android-after-a-reb
BUT I am starting to wonder and have a second question. SHOULD I instead change my architecture such that I have to have a server portion and fire notifications through Google FCM api instead to send notifications to my app every day to potentially reschedule alarms that are dead since the phone rebooted. Is there even a way to see if my notifications are still scheduled and will go off at the correct times?
thanks,
Dean
I put a very detailed answer on your mentioned question, but I will also chime in here.
SHOULD I instead change my architecture such that I have to have a server portion and fire notifications through Google FCM api instead to send notifications to my app every day to potentially reschedule alarms that are dead since the phone rebooted.
Short answer, no.
Long answer, if you are using FCM to trigger a daily check to ensure that all notifications are scheduled, then why not just use it to trigger the reminder notifications themselves? FCM has high-priority messages that will wake the phone and allow your application to execute some code. However, if you are planning on releasing this application to the public, this ends up creating a privacy issue that isn't present if the application keeps all information local. If you are the only user, then it makes even less sense to use a server to handle anything. If it is for a couple of friends, then a server MIGHT be an option, but I would still recommend against it even if they are fine without a privacy policy and the such because it is an unnecessary additional cost to the application.
Is there even a way to see if my notifications are still scheduled and will go off at the correct times?
If my answer above didn't already take care of this, while it might be technically possible to discover whether or not your application has any pending Alarms set with AlarmManager, it is not feasible to do so. AlarmManager does not provide any sort of visibility to any set alarms (see this answer). You would have to figure out some way to keep track of this yourself, but like I mentioned in the first part, if you are going to us FCM to trigger a job to schedule the notifications you may as well use FCM to trigger the notifications.
I have been testing an app for many months which uses the Android Geofencing API to track enter/exit events. It works flawlessly about 99% of the time, but there are random times when the geofences simply do not trigger.
This cannot be an issue caused by my application failing to keep the geofences loaded, because whenever the fences fail to trigger, opening a completely separate GPS application, ie google maps, immediately causes my application to trigger the geofence event that it had failed to.
I am handling the reloading of the fences through a broadcast receiver on BOOT_COMPLETED and location.PROVIDER_CHANGED.
The fence radius is reasonably large, over 1 mile.
The app is not being put to sleep or under power management.
Users and personal testing show this is never due to location services being disabled manually.
There is no dwell and the fences never expire.
As I said, the geofences work flawlessly 99% of the time, and the other 1% simply opening another gps application immediately triggers the fences. I'm trying to figure out what I can do to eliminate the failing 1%, hopefully something short of constantly polling location (which makes the geofencing api pointless anyway).
Update: (Limited testing sample size of 1)On a device running Android Oreo, this issue seems to have become exacerbated to the point of geofences never triggering unless a secondary gps app is launched...
I don't know if this will help anybody but with the Background limitations starting from Android O the geofences work as you described, only opening apps that get the current location of the user will trigger the geofences.
You can create a Foreground service and poll the location from the Fused Location Provider in order to make Geofences to actually work.
I hope someone else found a better solution.
I need to send what businesses the user is currently at every 5 minutes. I am using the Google Places library and can successfully grab the businesses. The problem is this service needs to be going 24/7.
My solution so far is to use a service called from my main activity. This service will subscribe to background location updates every 5 minutes. Once the location update comes through, it will ask the Google Place library for the businesses the user is currently at. I am using the Google Play Services to subscribe to these location updates. I read that using an Alarm for something like this isn't recommended, that is why I am subscribing to location updates to give me a pseudo setTimeout(5mins) behavior. I am actually not even using the GPS returned, just the function callback to ask GooglePlaces.
The problem is that this service is unbelievably unreliable. I am running Android 8.0 with 11.2.0 play services installed. The service's OnDestroy is called within a few minutes and is never restarted even though I return Start_sticky from the service OnStartCommand. Are services supposed to get killed this quickly? I have no other apps open and the service is 99% of the time just idle waiting for the location tick to come through.
Is there a better way to do this? All I really need is a function called every 5 minutes so I can ask Google Place where the user is at. It doesn't even have to be location related. The only requirements are it runs even when the app is closed.
Try to use AlarmManager with service... try this once maybe it will solve your problem.
Thanks!!!
My solution was to use AlarmManager started from my Activity. No Services needed.
I'm trying to find out if the Google Play Services geofencing and location system can be practically used for background location monitoring.
An example scenario is that I have the phone in my pocket, and enter a geofenced area - will the event handler in my app be triggered so I can deal with the event as appropriate, or is the system only intended to be used whilst the phone is awake and the app in the foreground?
I've been banging away at the example code, and so far haven't managed to make it work in this way - or find docs fully addressing this - it seems to be too new for people to be using it much.
Obviously the phone doesn't use GPS continually whilst sleeping, or the battery would run down quickly, but I'm wondering if the broad network location is monitored and used for this purpose (or to discover if the device is within short distance of a geofence, to know that it's worth polling the GPS periodically to find if it has been crossed.)
This answer (by Commonsware) to another question seems to answer the general thrust of the question, though more testing is required to answer some of the more detailed aspects about background location availability, accuracy and geofence reliability.
Commonsware
Geofence if implemented properly will work even when your app is in background and it can be handled from ReceiveTransitionsIntentService In the Service you can create notification and alert the Users to bring back to your APP.
But As per the Documentation, If the Location Services is Disabled by the User on the Device your Registered Geofences will be removed and you have to Re-add all the Geofences. (NOT SURE HOW CAN WE ADD THE GEOFENCES BACK in BACKGROUND DID NOT FIGURE OUT THE SOLUTION YET FOR THIS)
Also in other cases like when the Device is Switched Off / Battery is Drained / Restarted Most probably the Geofences are Removed and we have to reset the Geofences back (However i cannot confirm this as have not found this anywhere in documentation but while testing i have figured out this issue)
I just finished the tutorial for geofencing on Android (http://developer.android.com/training/location/geofencing.html) and I wonder why the 'callback' for geofences are done via pending intents and not a simple callback interface.
If implemented in an activity, one would usually disconnect the location client in onPause() anyway, so previously added geofences would not be tracked either after the application paused/was destroyed, so why a pending intent? Or am I mistaken here?
I wonder why the 'callback' for geofences are done via pending intents and not a simple callback interface.
Mostly because geofences are designed to work even without your application running.
If implemented in an activity, one would usually disconnect the location client in onPause() anyway, so previously added geofences would not be tracked either after the application paused/was destroyed, so why a pending intent? Or am I mistaken here?
I believe that you are mistaken here. In fact, geofences specifically are not designed for directly triggering UI, as is discussed in the documentation:
The Intent sent from Location Services can trigger various actions in your app, but you should not have it start an activity or fragment, because components should only become visible in response to a user action.
Now, you might elect to say that you want to only use geofences while you have your activity in the foreground. However, you would have to remove those geofences in onPause(). A geofence will remain registered until its expiration time or manually removed, AFAICT.
This answer can be outdated - accuracy and realiability of google play services has changed a lot from it's initial release.
Some of my experiences with geofencing below.
First of all - the main advantage of this technology is VERY low battery usage. In the fact, I can't notice any changes in battery life. It's really impressive.
Service seems to use only Wi-Fi and network location. I didn't notice GPS running at all. I can't say if it's only hidden location icon or really not using GPS.
Accuracy - it's terrible. 20 circle areas are not detected at all, except range of my home ap. It looks like whole position circle, including error must be inside of fenced area. 1000m areas are detected sometimes and with huge latency. Those experiments where made in open area with very low number of Wi-Fi ap around. I'm still trying to find really reliable settings foot this service. After getting intents I want to turn on GPS location and make final approach in my own code.