I am currently developing an android application where I need to setup persistent alarms that will fire on a specific date and time and show a notification. It works well but the system clears all alarms upon rebooting.
From other questions I know that if I create a BroadcastReceiver forBOOT_COMPLETED I can rearm canceled alarms. My question is: What information about those alarms I need to keep in order to rearm them when needed?
Some people say that I need to persist all the Intent extras and the fire datetime in order to recreate the PendingIntent upon rebooting.
Others say that if I only persist the requestCode for the PendingIntent, after reboot I can use this code to get the canceled PendingIntent and rearm the alarm, because when the device reboots the PendingIntent's are just canceled instead of deleted.
Which one is right way to do it?
PendingIntents will not persist after reboot, so to be safe just restart your alarms in the BroadcastReceiver with all the intent extras that you make when you first initialized the alarm, and keep the requestcode the same.
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'm trying to make a task schedule app and I made an Alarm app trying to learn how to do that part at least. It uses AlarmManager and it makes an alarm go off at a time chosen by a TimePicker. But it doesn't work when the emulator is turned off and on again.
So I'm trying to use BroadcastReceiver but I don't understand any of the guides...I mean am I supposed to set the intent that the alarm manager does to the BroadcastReciever? Or can I just start up the app and then the alarm exists again or what? How are the alarms stored in android?
But it doesn't work when the emulator is turned off and on again.
That is the correct behavior -- AlarmManager's schedule is cleared on a reboot. You need to specifically register to receive the ACTION_BOOT_COMPLETED broadcast, in order to re-establish your alarm events after a reboot.
I mean am I supposed to set the intent that the alarm manager does to the BroadcastReciever?
Well, if you are using a _WAKEUP-style alarm, the recipe is to use a getBroadcast() PendingIntent with AlarmManager, where the BroadcastReceiver is either a WakefulBroadcastReceiver (and follows those instructions) or passes control to my WakefulIntentService.
I have somewhat-contrived examples of using WakefulIntentService and WakefulBroadcastRecevier.
How are the alarms stored in android?
AFAIK, they are held in the memory of a core OS process and are not persisted.
I'm new to Android so I want to make sure that the following solution is the correct one.
The problem:
I want to sync the device's local database with a database on my server, via a webservice, every 10 minutes. I already have a web service call that I can make that returns the new/updated records. What I'm wondering is what is the best way to schedule this task. I want the databases to sync even when the application is not running.
My solution (is this the correct route to go?):
I will have one BroadcastReceiver that listens for android.intent.action.BOOT_COMPLETED, in it's onReceive I will create an AlarmManager that sends a message to MyReceiver (via a PendingIntent) every 10 minutes. Also, in my application's startup I will do the same (create an alarm to send messages to the MyReceiver via a PendingIntent) - Since both alarms are sending messages to MyReceiver and their corresponding PendingIntents are initialized with PendingIntent.FLAG_UPDATE_CURRENT will the new alarm override the old one? (this is what I want to do, in case for some reason the alarm gets cancelled after device boot it should be restarted when the application starts).
In MyReceiver's onReceive() I will create a MyIntentService (this instance will make the webservice call and update the local database).
Is this a good solution? Any suggestions?
Thanks
Solution is fine...Actually all the AlarmManager instances get cleared when device turned off and rebooted.
The simple way is that...
First create AlarmManager when application started.
Second in onReceive of BOOT_COMPLETED BroadcastReceiver.
Its enough, PendingIntent.FLAG_UPDATE_CURRENT will make sure of having only one activated alarm at a time.
In this way, alarm registered when your application started. There will be no issue if its already registered via BOOT_COMPLETED. Activated alarm will deactivated when you turn off your device, but BroadcastReceiver to BOOT_COMPLETED will take care of registration new alarm at next boot.
If you decide that this answers your question, please mark it as "accepted". This will raise both your and my reputation score.
Also you need to review your interval to use network, it might be very resource consuming for device and user. One policy might be to have longer period of interval and check for update when user starts your app (this might not be user friendly but can save many system resources and battery power as well). Try to find some better policy according to your needs.
Using FLAG_UPDATE_CURRENT in that manner will override the existing PendingIntent if one exists. I'm not positive but I believe that as soon as you get into onReceive, the PendingIntent is consumed so it's no longer there to be overridden. In either case, it sounds like this is the functionality you are looking for and yes it's a good way to solve this kind of problem. My only other suggestion would be if the 10 minute interval timing is not absolutely critical then use one of the INTERVAL_ schedules (INTERVAL_FIFTEEN_MINUTES for example) in your AlarmManager to help conserve battery life; basically it lets allows all apps that run on intervals to "batch" their work together and wake the device up less frequently.
Alright so I'm working on a project where I want the app to check the internet for updates. I also want the user to be able to customize how often it makes these checks.
I'm kinda struggling with how I go about doing this.
I'm thinking I have a BroadcastReceiver check for the Intent.ACTION_BOOT_COMPLETED, and then start the AlarmService based upon a variable already set somewhere.
But what happens if the user wants to update the interval? How do I stop the old AlarmService and replace it with the new one?
Also how do I have my AlarmService run a "background update" portion in my app without actually running any of the activities?
EDIT: Also can someone advise if I'm using the AlarmService correctly? I'd want to check for updates fairly frequently, should I be using some other method? I'd check between 1-5 minutes.
I do a similar thing in my app. I basically have two services: one that sets the alarm and the other that does the actual donwloading.
When your BroadcastReceiver get's the intent ACTION_BOOT_COMPLETED you start your alarmService which sends an broadcast to start the downloadService.
So your BroadcastReceiver does both things: starts the alarmServcie if intent == BOOT_COMPLETED else it starts the downloadservice.
Also if the user changes the periods in which he wants those updates to be done you store the chosen value in the preferences, start the alarmservice and retrieve the values to set up a new period, e. g. 1 hour, 2 hours
Edit: Here is the info some info from the docs about pending Intents and how to cancel them. http://developer.android.com/reference/android/app/PendingIntent.html
When the user changes the interval you should first cancel your old alarmservice and then set it again.
I am setting an alarm for my reminder app:
PendingIntent sender = PendingIntent.getBroadcast(AddToDoList.this,
Integer.parseInt(DBHelperClass.getMaxPrimaryId()), intent, 0);
i am using a unique value (primary ID) to set an alarm. When i want to edit the alarm i am using the same key. But what i see is that both the alarms go off! original as well as edited one.
how do i cancel the old alarm ?
Also these alarms are not working once i switchOff & then again switchOn my device .
how do i cancel the old alarm ?
Call cancel() with your original PendingIntent.
Also these alarms are not working once
i switchOff & then again switchOn my
device .
Alarms do not persist after a reboot. You will need to reschedule the alarms, possibly by a BroadcastReceiver that gets control at boot time.
You should consider changing the way you make Intents unique - requestCode is not officially defined. Try keeping Intent's data different for example.
About persisting the alarm trough reboots, I'm not sure but maybe RTC_WAKEUP flag is the closest you can get.