The App Clinic: Cricket
+DevBytes: Efficient Data Transfers
+Alarms (based on the {@link android.app.AlarmManager} class) give you a way to perform time-based operations outside the lifetime of your application. For example, you could use an alarm to initiate a long-running operation, such @@ -55,6 +71,76 @@ instead consider using the {@link android.os.Handler} class in conjunction with {@link java.util.Timer} and {@link java.lang.Thread}. This approach gives Android better control over system resources.
+A repeating alarm is a relatively simple mechanism with limited flexibility. +It may +not be the best choice for your app, particularly if you need to trigger network +operations. A poorly designed alarm can cause battery drain and put a significant load on +servers.
+ +A common scenario for triggering an operation outside the lifetime of your app is +syncing data with a server. This is a case where you might be tempted to use a +repeating alarm. But if you own the server that is hosting your app's +data, using Google Cloud Messaging (GCM) +in conjunction with sync adapter +is a better solution than {@link android.app.AlarmManager}. A sync adapter gives you all +the same scheduling options as {@link android.app.AlarmManager}, but it offers +you significantly more flexibility. For example, +a sync could be based on a "new data" message from the server/device (see +Running a Sync +Adapter for details), the user's activity (or inactivity), the time of day, and so on. +See the linked videos at the top of this page for a detailed discussion of when and how +to use GCM and sync adapter.
+ +Every choice you make in designing your repeating alarm can have consequences in how your +app uses (or abuses) system resources. For example, imagine a popular app that +syncs with a server. If the sync operation is based on clock time and every instance of the +app syncs at 11:00 p.m., the load on the server could result in high latency or even +"denial of service." Follow these best practices in using alarms:
+ +Use {@link android.app.AlarmManager#setInexactRepeating setInexactRepeating()} instead +of {@link android.app.AlarmManager#setRepeating setRepeating()}. +When you use {@link android.app.AlarmManager#setInexactRepeating setInexactRepeating()}, +Android synchronizes repeating alarms from multiple apps and fires +them at the same time. This reduces the total number of times the system must wake the +device, thus reducing drain on the battery. As of Android 4.4 +(API Level 19), all repeating alarms are inexact. Note that while +{@link android.app.AlarmManager#setInexactRepeating setInexactRepeating()} is an +improvement over {@link android.app.AlarmManager#setRepeating setRepeating()}, it can +still overwhelm a server if every instance of an app hits the server around the same time. +Therefore, for network requests, add some randomness to your alarms, as discussed above.
+Repeating alarms that are based on a precise trigger time don't scale well. +Use {@link android.app.AlarmManager#ELAPSED_REALTIME} if you can. The different alarm +types are described in more detail in the following section.
+ +As described above, repeating alarms are a good choice for scheduling regular events or @@ -69,29 +155,6 @@ immediately. that uses the same pending intent, it replaces the original alarm. -
Every choice you make in designing your repeating alarm can have consequences in how your -app uses (or abuses) system resources. Even a carefully managed alarm can have a major impact -on battery life. Follow these guidelines as you design your app:
- -If you need your alarm to fire at a particular time of day, then choose one of the clock-based real time clock types. Note, however, that this approach can have some drawbacks—the app may not translate well to other locales, and if the user -changes the device's time setting, it could cause unexpected behavior in your app.
+changes the device's time setting, it could cause unexpected behavior in your app. Using a +real time clock alarm type also does not scale well, as discussed above. We recommend +that you use a "elapsed real time" alarm if you can.Here is the list of types: