In my app I would like that a certain method of mine (call it toSched) will run at a given time in the future (I'm using Timestamp for knowing when).
How can this be done, and is it possible to do it even if the phone is turned off (assume there is enough battery) ?
*I know I should use AlarmManager but I'm not sure how
You want to use the Android Alarm Manager. You do it by creating a PendingIntent (which is what you want to run) and then calling the set method. Checkout this stackoverflow post for more info.
What most people do is create a PendingIntent that is a broadcast. Then they create a broadcast receiver to receive that broadcast and do what ever is supposed to be done. Here's an example of "calling a method" to start an activity. But you can just put your own arbitrary code in the receiver to do what ever random task.
There's several ways of looking at this. One alternative (the one I think you're looking for) is discussed in this Stack Overflow thread:
How to set a timer in android
Another is to make sure your program gets invoked when you need it to:
AlarmManager
... or ...
cron
Related
I'm developing a little Android app, that needs to run a background process, used to start a remote connection periodically (for example, to check if there is new data on the server). This process obviously needs to work also if the application activity is not running at the moment.
As I can see in documentation, there are two types of approach to develop a scheduled background process in Android, working also when the application is closed.
Services
Alarms
The first one is not so good for my requirementes, because it can be killed by OS in case of low memory, so it is useless for me. startForeground() is not so good because I want the process is silent.
Alarm is ok, because it can't be killed by the OS, so it can work indefinitely. But... If I schedule an Intent with the AlarmManager, how can I preserve a reference to the Intent, surviving at application restart?
For example, if I want to cancel, or reschedule the Alarm, I need the reference to the initial Intent to cancel it thorugh the "AlarmManager.cancel(Intent i)" method. But if the application was restarted by the user, how can I obtain a reference to the initial Intent that was used to start the alarm?
Is there another way to stop an alarm if the launching application was restarted?
about alarms, you can cancel using the intent characteristics, so you don't need a reference to the original intent. In any case, the alarms mechanism still need you to run something on a service.
In any case, you missed another possible solution: SyncAdapter. Its purpose is to sync with servers, but you can do whatever you wish in the code, and it's unlikely the OS will kill it, as opposed to the other solutions you've mentioned.
Sadly even now it lacks on documentation and samples, but I think it can fulfill your needs. Here's what I've found
yes, note that cancel is looking for a PendingIntent, not an Intent per se.
so
PendingIntent pendingIntent = PendingIntent.getBroadcast(this, R.string.some_string, new Intent(this, InitialIntent.class), 0);
AlarmManager alarmManager = (AlarmManager) getSystemService(ALARM_SERVICE);
alarmManager.cancel(pendingIntent);
gets you where you want to be.
note that I'm not getString'ing that string, that's becasue I want a unique Id/request code for this intent that I'm not going to screw up copypasting; I reference the same number when creating the alarm in InititalIntent.
This question was just answered, here:
How can I get the context of other activity?
Just cancel the intent you scheduled
Your best bet would be to make use to push notification (via GCM), whenever something new is available on the server. I am working on similar application where data can be pushed from one side (producers) and needs to be pushed to the consumer apps.
You need to look at BroadcastReceiver and GCM specific communication model. Hope this helps
I currently have an AlarmManager with BroadcastReceiver implementation as my Alarm. There is one major flaw with this though; it does not go off when force closing the app. I tested out what happens with ICS calendar app, and it goes off even if I force close it. I know some people will say "if the user closes the app in that manner, they do not want it going off." What about task killers? That is the case I am looking for. Its pretty obvious my method cannot accomplish this, and I have looked and looked, but most if not all the examples are like how I implemented it. Any ideas how I can accomplish this?
Edit: So it seems all the research I've done that what I want to do is not possible without having the user install two separate apps, which is not ideal. There is a possibility that Google just made there Calendar app in that way (since they do write the source code), because I tested the top Calendar apps on the market and they all did not go off when the user force closed the app. So this begs the question, simply put, can this even be done in a single application? It is looking slim that it can be done due to Google trying to curb developers from not allowing the user control over random running broadcasts or services, which is understandable. Hopefully this helps others quickly realize there really isn't a real way to actually do this. All you can do is warn the user, that in closing your app in that manner they will not get alarms; enough said.
I would not use a Broadcast Receiver with your alarm
Broadcast Receivers in general provide two functions
1) Listen to broadcasts from the system
2) Allow apps outside of your own to make requests of your app.
Alarm Manager sets up new alarms with:
set(int type, long triggerAtMillis, PendingIntent operation)
Schedule an alarm. (from Android Documentation)
The Pending Intent placed in there is the intent that will be fired when the Alarm is up. You can have this Intent begin a Service by placing the service in the intent.
Ex:
Intent i = new Intent(context, MyService.class)
Where MyService is a class that extends Service. (you can just as easily do an activity, but having activities popping up out of nowhere is terrible design.
A Service is like an Activity that has no UI. Basically you can have it perform some background functions and possibly post a notification to the user that something has occurred.
I'm implementing an background process that will update information my app uses.
I only want this process to update say once a day, if the process gets data newer than what it had before I want to present the user with a notification, exactly like twitter/gmail does.
I want the update process to run automatically, even when the main app is not open.
Is a Service the best way to go? I've been reading quite a bit about this, I figured a service running all the time for something that is only going to do work once a day seems a little overkill.
However I notice google run service for friendlocation and google+ services continuously on my nexus.
I've look into starting my service via the AlarmManager so its only started when required.
Some posts also suggest using the Handler class, I don't think this will work.
Just looking for the best practice here.
I figured a service running all the time for something that is only going to do work once a day seems a little overkill.
Absolutely.
I've look into starting my service via the AlarmManager so its only started when required.
This is the correct answer.
If you only want your code to be invoked if the device is on, implement an IntentService, do your work in its onHandleIntent(), and have AlarmManager start up the service on your desired schedule.
If you want your code to force the phone to wake up, you can do that, but you will need to use a _WAKEUP-style alarm, and you will probably want to look at my WakefulIntentService, designed to handle this pattern.
What is the best practice to create a scheduled notification at some point in the future?
I have found a way using a Service that is triggered with a PendingIntent via the AlarmManager. In the onCreate() method of the Service I create the notification. This seems a bit like abusing the service to do something it is not supposed to be doing.
Is there another less cumbersome / more elegant method of achieving the same end? (The use case in question is giving the user a daily reminder to do something with my app)
What is the best practice to create a scheduled notification at some point in the future?
AlarmManager.
This seems a bit like abusing the service to do something it is not supposed to be doing.
Ummm...why?
Is there another less cumbersome / more elegant method of achieving the same end?
Setting an alarm requires a total of 3 to 4 Java statements, plus one for any extra you package into the Intent. Processing the alarm in a BroadcastReceiver to go raise a Notification regarding the "daily reminder" should be another ~20 lines of code, plus one entry in the manifest.
I am writing an app which needs to periodically check the server for new messages and notify the user. I have seen some examples using AlarmManager to hit a BroadcastReciever which seems like the right thing to do, but i cant seem to get it to work.
Can anyone show me a step by step tutorial for this sort of thing (repeating alarm which triggers some kind of background code that fires a Notification)?
TIA
Here is one complete example: http://android-in-practice.googlecode.com/svn/trunk/ch02/DealDroidWithService/
The pattern this example uses, and one that I've found that seems to work well, is to use a boot receiver to setup the AlarmManager (and of course also check to start the polling from your main Activity too, for the case when your app is installed and the system is not booted) and have the AlarmManager send an Intent for another receiver: http://android-in-practice.googlecode.com/svn/trunk/ch02/DealDroidWithService/src/com/manning/aip/dealdroid/DealBootReceiver.java
And then from the AlarmReceiver start an IntentService:
http://android-in-practice.googlecode.com/svn/trunk/ch02/DealDroidWithService/src/com/manning/aip/dealdroid/DealAlarmReceiver.java
From your IntentService then make your network call to poll for data, or whatever you need to do. IntentService automatically puts your work in a background thread, it's very handy:
http://android-in-practice.googlecode.com/svn/trunk/ch02/DealDroidWithService/src/com/manning/aip/dealdroid/DealService.java
Check the docs for these classes too, a lot of into in there.
The caveat with this example is that it does not deal with the wake lock gap (the excellent CommonsWare code does that if you need it), but it may give you some more ideas about how to potentially address the "poll using AlarmManager and Service" stuff.
UPDATE: the code is now here: https://github.com/charlieCollins/android-in-practice