Hello all i want location updates when my app is triggered first and after even it is killed i want my service to run i tried broadcast receiver for this purpose but it run on phone reboot Can anybody guide me to the right direction? Thanks
depending on the layout of your code, I believe it might be as easy as making the app perform the location update request on onResume while leaving onPause blank to test if it works for what you want. At least if I understood you correctly, that's what worked for me but it might drain your battery if you are using some power demanding location provider like GPS. And about your service to survive reboot I'm not really acquainted on that topic but from a quick read, indeed using broadcast receiver and listening for BOOT_COMPLETED to set off an intent.setAction declared after onCreate on your MainActivity should do it, but haven't tested that myself yet. Anyhow, it would be best if you can post the code you're working with so that others can see exactly what you have so far and be more helpful.
Hope it helps
Related
i used the google simple code to "Creating and Monitoring Geofences" and every thing works fine but i have one problem that when the device lost gps signal for second the trigger event will count this as exit , and when signal back will count as enter
even it's still inside Geofence ,i guess i can't avoid this situation
so did any one know if this behavior can be suppressed?
also An additional questions, i read alot in stackoverflow geofence problems that using a BroadcastReceiver better than Service to receive the transitions
right now i use service to receive and it's work fine , Is it necessary change it to BroadcastReceiver ?
This is an issue with Google Geofence relying on bad network location points at times. I have a potential solution for this here. It's not 100%, but it does help suppress the geofence jumps.
As for the second part of your question, I don't know if you mean the IntentService or just a Service. If it is a Service, I would recommend using an IntentService or BroadcastReceiver. IntentServices are mostly used for performing tasks on a background thread, where BroadcastReceivers are meant to restart the process (if it wasn't force killed by the user), and perform a quick task to handle the intent. Both of those are self contained, and destroy themselves right after the task is done. But to answer your question, no, you don't have to use a BroadcastReceiver, but it is better practice to do so.
I want to fetch the current Location of the user in background. I know how it can be done using Service in Android. But I would like to know is there any possibilities to get user Location without running service. Like using BroadcastReceiver or anything? I'm just trying to avoid running Service to fetch Location.
For Example I referred this link. But I couldn't follow how to do like this.
Any help will be appreciated. Correct me in case I'm asking anything wrong.
EDIT: Oh, I think in the above link he is using Service to get the Location. So I think it's not possible to get location in background without running a Service. Still suggestions are welcomed.
You Should Implement a BroadcastReceiver that receives alarm every 2 hours. That alarm is Set by Your Activity.
When the alarm is triggered by your System, Broadcast Receiver receives it, Executes Your Process in BroadCastReceiver.
This is what i can think of.
I need to submit some data as soon as there is an internet connection. Until now I've done this by registering a broadcast receiver in the manifest for the CONNECTIVITY_ACTION event. This works perfectly but now I'm worried about the performance.
I mean a CONNECTIVITY_ACTION broadcast is sent pretty often sometimes and the every time my app will be "started" just to try to submit some data, that might not even exist at that moment.
Is there a better way to do that? Or does it not really matter?
I mean I could register a receiver in every activity but that's not very neat I think. I know I could make a class derive from Activity (to override onResume and onPause) but as I'm also using FragmentActivity, that isn't the best option either.
Do you have some suggestions on how to do that? The data doesn't need to be sent immediately if a connection is available (I mean that would be very nice but not necessary).
I could also just try to send the data in the onResume method of every activity but again that's not as neat as I'd like it...
Many apps fire up receiving that broadcast. Check the logcat yourself. Some apps have a running service that check for a connection, vomiting out exceptions.
As many times stated by Google engineers, it's less taxing on the battery to do your tasks upon radio being in active mode and do some extra for caching, than to wind up radio every few minutes. Refer to 2012 Google I/O speech by Reto Meier. He outlines a bit how it should work and why.
#commonsware let me start by saying thanks for all the help that you give this community, i swear the majority of issues that i google you were the accepted answer.
anyway, had a few questions after i started using the locationpoller
as noted in another post, once i start your polling service, i occasionally get this:
03-07 15:42:03.260: W/MessageQueue(14699): Handler (android.location.LocationManager$ListenerTransport$1) {419425f8} sending message to a Handler on a dead thread
is this a concern still? i couldn't tell if this was just something the locationmanager is screwing up of it was maybe the timeout handler
next is my main concern for creating this post:
i need to track users while their screen is off as part of a destination aware navigation-like application, and for some reason its not waking up after going underground for a while.
i get some weird test results when playing with no network too. for now i start the service like you suggest
Intent i=new Intent(this, LocationPoller.class);
i.putExtra(LocationPoller.EXTRA_INTENT, new Intent(this, LocationReceiver.class));
i.putExtra(LocationPoller.EXTRA_PROVIDER, LocationManager.NETWORK_PROVIDER);
everything seems to work as u documented, when testing with airplane mode turned on PollerThread#onPreExecute() gets called every time, and then never makes it to the end, and 2 minutes later, my receiver finally gets notified when the onTimeout Runnable gets triggered.
then when i turn airplane mode off again, everything seems to go back to normal, with my receiver eventually catching up again.
My issue is that when i test in the real world, and take the subway home but leave the app and service running, once i reconnect above ground, i cant seem to find any trace in the logs that the service continues on, and my receiver, which uses another wakelock to turn the screen back on / send a notification when close to your destination, never gets triggered until i re-open my app
long story short - is this an issue with the library? an issue with how locationmanager works? have you any ideas on a better way to test this rather than just using airplane mode?
above ground, biking around, driving, etc, everything seems to work just fine, but once i introduce the subway and i lose all connections, shit stops working, and i just dont know enough about the finer points of locationmanager to understand why the service seems to stop
disclaimer this app isn't meant for people on the subway but im just not sure (havent had any way to test) if a user is out in the middle of nowhere and loses network connectivity i hope they dont lose tracking as well (since they can choose to just use network provider or gps depending on the settings)
is this a concern still?
I have no idea. If you can create a reproducible test case that demonstrates this, please post an issue to the project's issue tracker.
My issue is that when i test in the real world, and take the subway home but leave the app and service running, once i reconnect above ground, i cant seem to find any trace in the logs that the service continues on
The service is not supposed to "continue on". The service will try for a short while to get a location fix, then will shut down after delivering the timeout message. It is up to you, via AlarmManager or similar means, to do the actual "polling".
Quoting the documentation:
You simply set up an AlarmManager alarm to contact LocationPoller on whatever frequency you wish, and it will handle all of the location work from there, sending you the results via a broadcast Intent... Next, you need to create an alarm via AlarmManager, so you can control how frequently the location is retrieved and whether it should wake up the device if it is asleep. Please do not request location updates frequently, as this will drain the user's battery, particularly if you are using GPS.
So, your first step would be to determine if your alarms are working properly. You can use adb shell dumpsys alarm to examine the registered alarms and see what is going on.
I have Android service to run and send email every 9 mins but after some cycles it quits. this app is also installed in my Android froyo but it works good for more than 2months now.. I can see the logs in logcat that the service quits but my problem is I cannot understand what does it mean.. Can someone help me with this? Thanks!! any help would be appreciated...
here is my source code:
https://gist.github.com/77a40ac93cd311acb56c
Logcat logs:
https://gist.github.com/dd3ab385d79253fac632
The point behind using AlarmManager is so that your service only needs to be in memory when it is doing actual work, and can go away in between AlarmManager events. You have managed to not do that, and therefore your code will not work reliably.
If you want to "send email every 9 mins", you should:
Move the BroadcastReceiver to be a public Java class, registered in the manifest via a <receiver> element, and remove the registerReceiver()/unregisterReceiver() stuff.
Switch your service to be an IntentService, so you get a background thread (which you need for your work, but your current code lacks) and so the service can automatically shut down when there is no more work to be done.
Add in the logic for the WakeLock that you will need since you are using a _WAKEUP-style alarm. You could combine this and the previous steps by switching to my WakefulIntentService, if you wish.
Deal with the case where the user reboots the device, if you want your alarms to continue after the reboot, such as by scheduling them again via an ACTION_BOOT_COMPLETED BroadcastReceiver.