Profile cover photo
Profile photo
Akhyar Amarullah
Software Engineer
Software Engineer
About
Akhyar's posts

Post has shared content
First law of software quality. Via +InfoQ
Photo

Post has shared content
Circle of Death via @joshsusser
Photo

Post has shared content

Post has shared content
A flowchart for background work, alarms, and your Android app
Pro-tip by +Ian Lake

For many apps, doing work in the background can be an important part of building a great experience. An alarm registered with AlarmManager (http://goo.gl/FtpShV) is one way to schedule your app to be run sometime in the future, even if your app isn’t in the foreground. What alarm type and API should you use for your app or are alarms even the best option? Let’s go through some of the factors that should influence your opinion:

How often do you want to trigger?
For events less than 60 seconds apart, alarms aren’t the best choice: use the much more efficient Handler (http://goo.gl/CE9vAw) for frequent work.

Want to set a user visible alarm clock?
On API 21+ devices, new APIs allow you to set a user visible alarm via setAlarmClock(): the system UI may display the time/an icon and apps can retrieve the next alarm clock with getNextAlarmClock(). Note that alarms set with setAlarmClock() work even when the device/app is idle (similar to setExactAndAllowWhileIdle()): getting you as close to an exact wake up call as possible. For backward compatibility, you’ll follow the same guide below for a single alarm.

Wake up the device/app while idle (i.e., doze, app standby)?
On Android 6.0+ (API 23) devices, additional power-savings optimizations (http://goo.gl/dVtgz6) have been added in the form of Doze (triggered by a completely stationary, unplugged, and idle device) and App Standby (triggered by an unplugged device on idle apps that haven’t been used recently). You’ll use setAndAllowWhileIdle() for inexact and setExactAndAllowWhileIdle() for exact alarms if you need it to fire an alarm while in these idle states. If it can wait until the user returns to their device/your app, use the standard set() and setExact() to be the best Android citizen and save your user’s battery.

(We’ll be talking more specifically about Doze and App Standby later!)

Just a single alarm?
A single alarm can be set with the aptly named set() method. One thing to keep in mind is that on API 19+ devices when you target API 19+, the system will be treated as inexact, potentially batching alarms together - the alarm will never go off before the time specified, but may go off afterwards. If you have some flexibility in the start time but have a hard deadline, consider using setWindow() to gain more control over the exact time period to be used.

You can use setExact() for a precisely timed single alarms on API 19+ devices, but use these only when the exact timing is required (such as with a calendar reminder).

Need to repeat at a constant rate?
For repeating alarms, batching is the key to good battery life. setInexactRepeating() does exactly that. Prior to API 19, you can use one of the INTERVAL_ constants (such as INTERVAL_HOUR to batch alarms of the same interval. On API 19+ devices, all repeating alarms (no matter what the interval) set with setInexactRepeating() will be batched.

You’ll note there’s also setRepeating() - similar to set() the behavior changes with API 19 from exact to inexact repeating alarms, meaning if you are on an API 19+ device and target API 19+, this functions identically to setInexactRepeating(). If you really need exact repeating alarms on API 19+, set an exact alarm with setExact() and schedule the next alarm once your alarm has triggered - keep in mind the battery implications though!

BUT WAIT: should you even use alarms?
If you want to be as battery efficient as possible (and you should!), consider using JobScheduler (https://goo.gl/CQjbsp) on API 21+ devices or GcmNetworkManager (https://goo.gl/CGNi3p) on all Google Play services enabled devices of API 9+.

Supporting both one off and periodic work, these APIs lack the ability to wake from idle, but gain the ability to wait for network access, wait until the battery is charging, take advantage of automatic backoff and retry, persist across reboots, and batch jobs across the system (meaning lower battery usage!).

That’s a lot of good reasons to use JobScheduler and GcmNetworkManager so consider them strongly in your push to #BuildBetterApps
Photo

Post has shared content
A flowchart for background work, alarms, and your Android app
Pro-tip by +Ian Lake

For many apps, doing work in the background can be an important part of building a great experience. An alarm registered with AlarmManager (http://goo.gl/FtpShV) is one way to schedule your app to be run sometime in the future, even if your app isn’t in the foreground. What alarm type and API should you use for your app or are alarms even the best option? Let’s go through some of the factors that should influence your opinion:

How often do you want to trigger?
For events less than 60 seconds apart, alarms aren’t the best choice: use the much more efficient Handler (http://goo.gl/CE9vAw) for frequent work.

Want to set a user visible alarm clock?
On API 21+ devices, new APIs allow you to set a user visible alarm via setAlarmClock(): the system UI may display the time/an icon and apps can retrieve the next alarm clock with getNextAlarmClock(). Note that alarms set with setAlarmClock() work even when the device/app is idle (similar to setExactAndAllowWhileIdle()): getting you as close to an exact wake up call as possible. For backward compatibility, you’ll follow the same guide below for a single alarm.

Wake up the device/app while idle (i.e., doze, app standby)?
On Android 6.0+ (API 23) devices, additional power-savings optimizations (http://goo.gl/dVtgz6) have been added in the form of Doze (triggered by a completely stationary, unplugged, and idle device) and App Standby (triggered by an unplugged device on idle apps that haven’t been used recently). You’ll use setAndAllowWhileIdle() for inexact and setExactAndAllowWhileIdle() for exact alarms if you need it to fire an alarm while in these idle states. If it can wait until the user returns to their device/your app, use the standard set() and setExact() to be the best Android citizen and save your user’s battery.

(We’ll be talking more specifically about Doze and App Standby later!)

Just a single alarm?
A single alarm can be set with the aptly named set() method. One thing to keep in mind is that on API 19+ devices when you target API 19+, the system will be treated as inexact, potentially batching alarms together - the alarm will never go off before the time specified, but may go off afterwards. If you have some flexibility in the start time but have a hard deadline, consider using setWindow() to gain more control over the exact time period to be used.

You can use setExact() for a precisely timed single alarms on API 19+ devices, but use these only when the exact timing is required (such as with a calendar reminder).

Need to repeat at a constant rate?
For repeating alarms, batching is the key to good battery life. setInexactRepeating() does exactly that. Prior to API 19, you can use one of the INTERVAL_ constants (such as INTERVAL_HOUR to batch alarms of the same interval. On API 19+ devices, all repeating alarms (no matter what the interval) set with setInexactRepeating() will be batched.

You’ll note there’s also setRepeating() - similar to set() the behavior changes with API 19 from exact to inexact repeating alarms, meaning if you are on an API 19+ device and target API 19+, this functions identically to setInexactRepeating(). If you really need exact repeating alarms on API 19+, set an exact alarm with setExact() and schedule the next alarm once your alarm has triggered - keep in mind the battery implications though!

BUT WAIT: should you even use alarms?
If you want to be as battery efficient as possible (and you should!), consider using JobScheduler (https://goo.gl/CQjbsp) on API 21+ devices or GcmNetworkManager (https://goo.gl/CGNi3p) on all Google Play services enabled devices of API 9+.

Supporting both one off and periodic work, these APIs lack the ability to wake from idle, but gain the ability to wait for network access, wait until the battery is charging, take advantage of automatic backoff and retry, persist across reboots, and batch jobs across the system (meaning lower battery usage!).

That’s a lot of good reasons to use JobScheduler and GcmNetworkManager so consider them strongly in your push to #BuildBetterApps
Photo

Post has shared content
A lesson in shortcuts.

Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on).  When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:
   if (name[0] == '.') continue;
This statement was a little shorter than what it should have been, which is
   if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;
but hey, it was easy.

Two things resulted.

First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.

Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.

I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.

How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about  40 years ago?

Keep that in mind next time you want to cut a corner in your code.

(For those who object that dot files serve a purpose, I don't dispute that but counter that it's the files that serve the purpose, not the convention for their names. They could just as easily be in $HOME/cfg or $HOME/lib, which is what we did in Plan 9, which had no dot files. Lessons can be learned.)

Post has shared content
Wait while more posts are being loaded