I'm writing an Android app widget that updates every minute with the current data. To update it, I'm using an AlarmManager that only works while the phone is not asleep:
AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
alarmManager.setRepeating(AlarmManager.RTC, calendar.getTimeInMillis(), INTERVAL_SEC * 1000, createFrequentUpdateIntent(context));
However, I'm facing the following challenge: when the phone wakes up after a long time, I want the user to see immediately that the data is obsolete because it hasn't been updated for hours. So I want to somehow mark the data as obsolete if there have been no updates for a long time.
I thought about hooking on the SCREEN_ON event, but apparently this is only possible through a background service and this is strongly discouraged (here and here).
Do you have any ideas of how to do this?
Thanks!
Perhaps in addition to the AlarmManager you could use the typical updateTimeMills update method, and have it called every 30m or so. When you get an update from this method, you could replace the widget with the "stale data" version of your layout, such that when the phone comes back on it's already been redrawn with the stale data notification.
In the event that this update triggers when your phone is on, you could just check for how recent the last update was, and then ignore it if the data is not stale.
I think that this would work because updateTimeMills update is called even when the phone is asleep, so it should still update when your AlarmManager is stopped.
Related
I am implementing a widget that checks on-line train departure times between every minute and every hour, depending on the time of day.
Calling the service with
manager.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
SystemClock.elapsedRealtime() - 10000, 60000, pendingIntent)
works fine, but for debugging I would like to reduce the interval to about 10 seconds which cannot be done because of the 1-minute limit in more recent versions of Android. Clearly, I don't care about battery life in the emulator.
As far as I understand, using an Hander/Timer is not an option, because it required the task to be in the foreground. Is a visible widget "in the forground"?
What is the recommended practice in this case?
you actually have to tasks
configure the alarmmanager to add/remove trigger events via intents
interprete the events with intents in a service
If you seperate both you can easily create a very simple gui/activity that does the same as the alarmmanager would do when being triggerd and that you can debug:
* onSendButtonClick: create and send pendingIntent
for the alarmmanager-handling i would implement logging into a text file each time alarmmanager is added/removed/triggered.
Be prepared that newer android versions may postpone alarmmanager events to save energy until the device is already active and that intervals less than 15 minutes may not work.
you may also need on_boot_complete to reconfigure alarmmanager after device-shutdown
Recently, in my timer app, running the timer for the first time causes it to fire an alarm approximately two or three seconds after it should. The strange this is, it only does this the first time I run the timer after installing the app via Android Studio. Every time after that, it runs as expected and the timer goes off after the expected time.
Here is the relevant code:
if(LOG) Log.v(TAG,"Starting the timer service: "+ TimerUtils.time2humanStr(context, mTime));
Intent intent = new Intent( this, TimerReceiver.class);
mPendingIntent = PendingIntent.getBroadcast( this, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
mAlarmMgr.set(AlarmManager.ELAPSED_REALTIME, SystemClock.elapsedRealtime() + mTime, mPendingIntent);
The variable mTime is set properly each time, according to the logcat output:
Starting the timer service: 5 seconds
And it works fine every time after the initial run. It was working fine before; could it be a problem with Android or Android Studio? Or am I needing to initialize something? I know I can't expect precise answers without dumping all my code here, I'm just looking for hints (speculation?) as to why this behaviour might be occurring.
Are you using API 19? Check out this note in the documentation:
Note: Beginning in API 19, the trigger time passed to this method is
treated as inexact: the alarm will not be delivered before this time,
but may be deferred and delivered some time later. The OS will use
this policy in order to "batch" alarms together across the entire
system, minimizing the number of times the device needs to "wake up"
and minimizing battery use. In general, alarms scheduled in the near
future will not be deferred as long as alarms scheduled far in the
future.
Source: AlarmManager
for example,An AlarmManager to count numbers at 7AM using Calendar was set.
But user turns off the android at 6am and turns on 8am.
So program does'nt count.
I dont think i can avoid this situation if i reset AlarmManager on receiver of BOOT COMPLETED.
Please tell me the way to count exact number in this situation.
You'd have to do a bit of work. Save the time of your next alarm in permanent storage (file, shared preference, or database). Whenever an alarm occurs, update this value. Set a BOOT_COMPLETED listener. When the boot completed listener launches, have it get the current time and check if its later than the time of the next alarm you stored. If so, you missed it. If not, you're ok.
Now if you have to worry about missing multiple alarms, it gets more complicated, but the idea is the same.
I would like to achieve this:
After first turning on the application, user receives notifications, every day at 2pm, if certain condition is true. If condition is false, we are not showing a notification this day. The condition is checked at 2pm, it downloads some data from the Internet.
So far I used AlarmManager and its method setRepeating() with 24h interval. AlarmManager fires up a Service. In this Service I'm downloading the data, checking condition and if it's true - showing Notification. Since downloading can last more than 5 seconds, I've declared android:process=":background" for this Service, to run it in separate process and not block my UI.
This approach has two drawbacks:
1: If user opens application let's say at 4pm (and the condition is true), he will receive the notification immediately. From setRepeating() documentation:
If the time occurs in the past, the alarm will be triggered
immediately, with an alarm count depending on how far in the past the
trigger time is relative to the repeat interval.
I would like that user will not receive a notification this day, only the next day and so on.
2: I'm worried that my notifications will not show after user switch the phone off. From AlarmManager documentation:
Registered alarms are retained while the device is asleep (and can optionally wake the device up if they go off during that time), but will be cleared if it is turned off and rebooted.
I don't know if it's possible to make it work all the time.
If you have any ideas how to make it better, you're welcome.
1: I'm not quite sure if i understood your question, but I think all you have to do is if it already is past 2pm add a day to 2pm:
GregorianCalendar twopm = new GregorianCalendar();
twopm.set(GregorianCalendar.HOUR_OF_DAY, 14);
twopm.set(GregorianCalendar.MINUTE, 0);
twopm.set(GregorianCalendar.SECOND, 0);
twopm.set(GregorianCalendar.MILLISECOND, 0);
if(twopm.before(new GregorianCalendar())){
twopm.add(GregorianCalendar.DAY_OF_MONTH, 1);
}
alarmManager.setRepeating(type, twopm.getTimeInMillis(), 1000*60*60*24, intent);
2: You could register a BroadcastReceiver for booting and start your alarm again there. Take a look at this: Android BroadcastReceiver on startup - keep running when Activity is in Background
I have an app which allows users to schedule alarms to sound at certain times, repeating at intervals of their choosing. I am using JSON to persist the alarm details, using SharedPreferences as storage.
I am using AlarmManager to schedule when my app should be notified that an alarm should sound to notify the user. I am currently using the setRepeating() method of AlarmManager, supplying the interval provided by the user. This works well, and in theory the app would never need to update the JSon which stores the next alarm time, as AlarmManager will just reschedule the next alarm time using the interval.
However, my thinking is that when the device is rebooted, I will need to supply a up to date alarm time to AlarmManager to avoid AlarmManager thinking an alarm has been missed as this is not necessarily the case.
So, what's the best way to do this?
update the JSon next alarm time when the alarm is sounded, even though this may not be necessary (setRepeating() handles this as long as there is no reboot)?
register for and listen for shutdown broadcasts and update JSon then (this raises questions - just how long will the app get to calculate and write alarm details to storage given that the phone is shutting down)?
don't update the JSon but add logic to the object which is woken by the AlarmManager to decide if the alarm just broadcast is valid and the user should be alerted?
I'm sure any of the above will work, but I can't decide which is the nicest way to do it.
This seems mostly a matter of choice. The problem you note parallels a general problem seen in Linux laptops and solved by anachrond. In my opinion, I would simply update the time and store it in SharedPreferences every time the event is received. Trying to listen for when the system shuts down might not be entirely reliable (what happens when your users -- probably drunk college students -- drop their device and the battery flies out?). Instead, I believe the best thing to do in this scenario would be to -- each time the alarm fires -- recalculate the time to send the next one, store it somewhere, and upon boot schedule appropriately.