I have an Android widget scheduled to update every hour
android:updatePeriodMillis="3600000"
However even when I change the system clock (forward one hour or more) the widget update method is not being called, no visual changes or logs happen.
I even wait a couple of minutes thinking that the OS may wait till the next minute because it doesn't need precision, but still nothing triggers.
Changing the system time won't trigger the basic widget updates?
You are doing right, but there is no guarantee it will be updated at exact time you expected. It could be delayed. Check the documentation.
The actual update is not guaranteed to occur exactly on time with this value.
The widget uses another internal clock to update itself, You'll need to wait 30 minutes in order to see the change and this cannot be hasted by changing the device's date.
If less time is required, then AlarmManager is the option.
IMPORTANT: If widget frequency is 30 minutes, ALL USERS will update the widget exactly at 00:00 and 00:30 of each hour. So if the widget consults a service the server will get peaks of requests every half an hour.
Related
I'm triggering notification for future time for my game. But it takes a lot of waiting time for the notification to trigger.
But when I change my device's local date-time to the 2-5 min before the scheduled time it doesn't trigger on scheduled time.
Can someone suggest me any explanation why is this happening only in Android device but not in iOS?
I am trying to use the GCMTaskManager to schedule a periodic task that runs approximately every 30 minutes. When it runs, it does an "update" on some internal data in the APP.
I have this preliminarily running and can see, using a LOG command in the OnRunTask, that the task fires as desired.I have it operating (at least according to a LOG I am populating when the OnRunTask fires.
I have two issues I can't determine if it can be done....
Is there a way to see how much time is "left" before the next OnRunTask fires... or... approximately what "time" it should run next? Example, if there is 30 minutes for the PeriodTask... and 18 minutes have lapsed, can we programmatically see that 12 minutes remain?
I have an internal "button" to manual fire the APPS update. If the user hits this, I want to "restart" the PeriodicTask timer from that point. That is, if the 30 minute OnRunTask is suppose to fire in approximately 12 minutes, and the user hits the UPDATE manually, I want the OnRunTask to now restart from for 30 minutes from the button press. Can this be done?
Thanks
Pete
For 1) GCMNetworkManager does not provide an interface for keeping track of the time elapsed/remaining but you can do so yourself by maintaining a variable storing the last updated timestamp for your data.
2) From the docs
When Google Play Services or the client app is updated, all scheduled tasks are removed. GcmNetworkManager invokes the client app’s onInitializeTasks(). Override this function to reschedule necessary tasks.
I'm trying to make an app that does certain tasks according to a certain battery level (say a notification when battery level reaches 10%).
The problem is when i launch it the app just checks the event once instead of continuous monitoring.
e.g. (say i launched the app when battery was 11%. Since the notification is scheduled at 10% it wont give any notification. It just check the event a single time instead of continuously monitoring i.e. when battery drains to 10% while running the app,nothing happens)
What is the possible solution to make the code run continuously ?
Try using the Alarm Manager Class: developer.android.com/training/scheduling/alarms.html.
If you pass in your battery check as the pending intent, the trigger time which is when you first want to check (In your case probably the interval time after the current time) and then an interval time (Too often can slow things down a lot, so try to find a time that suits your application, e.g. every few minutes.)
This should then fire on each interval which you could use to trigger your battery check and further functionality.
I'm developing an app that need to know the moment when the system startup, periodically.
I use System.currentTimeMillis(); to get the current "date" in millis.
I get the system elapsed real tine with SystemClock.elapsedRealTime().
I subtract the total time with the elapsed time, and I retrieve the system bootup time.
I would understand if the value change of milliseconds over time(different times in executing instructions). But for me it changes of seconds!!! Is very strange.
Someone have an idea of why?
Differences of seconds (or even tens of seconds) should not be surprising. "Current Time" corresponds to what the user perceives from the clock displayed. If you watch the displayed clock, it will not always change immediately. Read the docs:
http://developer.android.com/reference/android/os/SystemClock.html
It's pretty clear that you can't depend on currentTimeMillis for much of anything where you need millisecond accuracy. However, in most applications you really don't need that level of accuracy...
If you are trying to determine "exact boot time" from a specific moment in time later, a few seconds probably is the best you will do. Besides, what qualifies as "booted"?? When the kernel is loaded? When the user can interact with the device? When the device screen lights up? When the device can actually be unlocked?
You should probably just listen for RECEIVE_BOOT_COMPLETED (Android - Start service on boot).
Here is the Android doc: http://developer.android.com/reference/android/Manifest.permission.html#RECEIVE_BOOT_COMPLETED
I have found the following parts of code in a widget:
<appwidget-provider>
android:updatePeriodMillis="0"
<appwidget-provider/>
Now, my question is now that: what it does mean with updatePeriodMillis set to 0.
I know that it is set for the how often the widget will receive remoteview or others. so, what is the significance to set it to 0.
When you Set updatePeriodMillis to 0, You are actually disabling the update period on that particular widget. Means, that property is no more applicable to that widget.
According to android documentation:
The updatePeriodMillis attribute defines how often the App Widget framework should request an update from the AppWidgetProvider by calling the onUpdate() callback method. The actual update is not guaranteed to occur exactly on time with this value and we suggest updating as infrequently as possible—perhaps no more than once an hour to conserve the battery. You might also allow the user to adjust the frequency in a configuration—some people might want a stock ticker to update every 15 minutes, or maybe only four times a day.
Note: If the device is asleep when it is time for an update (as defined by updatePeriodMillis), then the device will wake up in order to perform the update. If you don't update more than once per hour, this probably won't cause significant problems for the battery life. If, however, you need to update more frequently and/or you do not need to update while the device is asleep, then you can instead perform updates based on an alarm that will not wake the device. To do so, set an alarm with an Intent that your AppWidgetProvider receives, using the AlarmManager. Set the alarm type to either ELAPSED_REALTIME or RTC, which will only deliver the alarm when the device is awake. Then set updatePeriodMillis to zero ("0").
According to Android developers
How often, in milliseconds, that this AppWidget wants to be updated. The AppWidget manager may place a limit on how often a AppWidget is updated.
This field corresponds to the android:updatePeriodMillis attribute in the AppWidget meta-data file.
Note: Updates requested with updatePeriodMillis will not be delivered more than once every 30 minutes.