I have written a small note program. Now I want to make it possible to add a reminder to each note (DD.MM.YY HH:MM). When the selected date has come, there should be a notification in the notification bar. If someone clicks on the notification, it should open that note.
My idea: I could make a (Intent)Service which runs all the time in background with alarm manager. That service (without app) has to be started after booting up.
Is there any better way like using the calender?
Thank you.
There is no way other than 'AlarmManager' class.
The AlarmManager doesn’t persist alarms; therefore, when the device reboots, you must set up the alarms again. If you don’t set up your alarms again, they simply don’t fire, because, to Android, they don’t exist.
You have to persistently store the remainder time of each note. And you have to register your application for boot notification. When the boot broadcast is received, the receiver needs to retrieve the stored notes and loop through each task and schedule an alarm for it, to ensure that your alarms don’t get lost in the reboot.
Related
I know how to create scheduled notification in Android by using alarm service but what I want to do now is to create notification in more frequent way.
For example, I want to push notification for 8 hours at the interval of 20 mins. In this case, is it efficient to use alarm service or timertask will be the better choice?
No matter which method, I wish to able to cancel it in the halfway. Thanks.
Timertask starts new thread and works in it. So if your app will work in background and your app will be closed by android, you won't receive any notification. AlarmManager provides access to the system alarm services. When an alarm goes off, the Intent that had been registered for it is broadcast by the system, automatically starting the target application if it is not already running. (link). So it will start your app even if it was closed. And you have to understand how you app will work with this notifications. If it works only while user works in app, you can use timertask, but if it has to work in background(for example you will receive notification even if user doesn't work with a phone/tablet), it will be better use alarmanager. Hope it helps.
I have two questions about alarms in android. My app sets alarms using alarm manager as requested by user
1- If my app is update (download an update from google play), will the alarms be lost and I have to reschedule them? Or they will still be triggered?
2- Upon my alarm expiry, I want to display Foo object to the screen. Currently, I have this Foo object serialized and passed as an intent extra with the alarm. is this Ok? Or should I pass the id, and upon the expiry extract that ID, call my SqlDatabase and construct the object accordingly?
Please help thanks
When the Alarm is very critical for the application, I usually check its existence (and create it if necessary) in the following events:
When device boots (android.intent.action.BOOT_COMPLETED)
When the app starts
When the app is updated (android.intent.action.PACKAGE_REPLACED), where I reset the alarms (cancel and re-create).
I cannot recall the exact reason, but I had a bug before with Alarms that occurs when the app gets updated, that's why I am listening for this and reset the Alarms.
I save Alarm information in SharedPreferences, so I can easily retrieve it and recreate the Alarm on crash.
For your second question, I think passing the id only is more efficient in terms of resources, but it depends on how frequently your Alarm will fire.
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.
Is there a way to send a notification to the user that app has been downloaded but a certain task from the app is not yet complete even after certain period - say a month. One way is a background service which should come alive every month in this case, check the app state (in sharedprefs) and then send a notification. Is there some other easier way in Android without writing custom service.
Here's how I would do it. Schedule an alarm using the AlarmManager to go off a month from today. That alarm can trigger some code inside of a Receiver or otherwise to check whether the said event has occured. If it hasn't, you can then show a Dialog or whatever.
In order to wake up your app after some amount of time (in your example a month) you're going to have to set an alarm. You can use AlarmManager for that. If all you're going to do is check SharedPreferences, you can do that in a broadcast receiver. You can send your notification there.
I see all the examples of AlarmManager being set by an Activity.
My question is this:
If my application sets a recurring AlarmManager, does that persist even after the application that started is is closed and removed from memory?
If not, how do I start an AlarmManager at a lower level that is started by Android at boot up and if it ever fails or dies or throws an exception is restarted without the user having to do anything?
Lastly, if the action I wish for the BroadcastReceiver to undertake has no visual components, do I still have to create a separate Activity for it? In my case I want there to be a background uploader that wakes up and looks into a folder and if it sees files in that folder, sends them off to the server. I don't need any feedback to the user.
So, my ideal would be to have a magical, OS based AlarmManager that calls an IntentService which just handles the uploading, but I'm unclear on how to get such an AlarmManager running in the first place.
TIA
Yes, AFAIK the alarms "survive" and keeps getting triggered, even after the activity that registered them ends. But they don't survive a phone reboot.
If I understands your problem correctly, I think you can achieve what your looking for by creating a project with a broadcast receiver that listens for android.intent.action.BOOT_COMPLETED intents and then (re-)register a repeating alarm, which in turns starts a (Intent)Service to do the uploading.
You don't need an activity, but you probably would want one anyway, to let the user temporarily disable the upload mechanism by checking off a checkbox, or something. It would probably also be nice to let the user choose the frequency of your alarm, i.e. how often the service should be started and look for new files to upload. This would also be a good place to register your alarm for the first time.
I agree with Nicolai that you'd have 2 broadcast receivers in your application :
one that re-register the alarm on boot
one that starts your service when triggered by the alarm
You could still have an activity but it shouldn't be started by the alarm receiver (hence the service) : instead, maybe launch a notification as you start your service, with the user having the possibility to launch the activity from the expanded message of the notification.
maybe also think about setInexactRepeating (instead of setRepeating) for your alarm, as well as using a worker thread to handle the long uploads (in case the user wants to use your activity in the main thread at the same time).