As presented during droidcon.de 2015
As an Android developers we use various frameworks and libraries provided by Google and others. Sometimes they are just a pure magic (say hi to Jake Wharton and his ActionBarShelock!) and sometimes… Well, if we make an effort to grap the source code and go through it, we realise there is no magic there. During my presentation, I will go deep into Lollipop’s new JobScheduler API. See what’s really there, how it’s advertised, and try to assess how big is the gap between us and guys at Google. Should we have any inferiority complex or could we write this code ourselves?
4. History
● originally as “What’s new in Lollipop”
● about new APIs
● how it works under the hood
● the devil is in the detail
http://nelenkov.blogspot.de/@kapitanpetko
5. What to look for
● technical information
a bit
● motivation
hopefully lot more
● are we rockstar devs
or not?
12. The APIs arms race
● each new release thousands new APIs
● iOS 8 includes over 4,000 new APIs
● thousands of new Material Designs or new
Bluetooth stacks?
13. The APIs arms race
● the more, the better
● … or just a marketing?
● Android Weekly pressure ;-)
55. Many Googles
● not the same Google for every one of us
● different search results
● different ads
● fine-grained targeting of contents
56.
57.
58.
59. Almost there...
● strong technology marketing
videos, blog posts, APIs arms race
● bold statements about possibilities
idle state, at night, next to the bed
● proven track record
search and ads tailored to our behaviour
61. // Policy: we decide that we're "idle" if the device has been unused
/
// screen off or dreaming for at least this long
private static final long INACTIVITY_IDLE_THRESHOLD = 71 * 60 * 1000;
// millis; 71 min
private static final long IDLE_WINDOW_SLOP = 5 * 60 * 1000;
// 5 minute window, to be nice
quotes are here ;-)
62. The “idle” state algorithm
1. display turns off
2. start the timer for 71 minutes +/- 5 minutes
3. alarm goes off
4. if screen still turned off
we are in the idle state
63. @Override
public void onReceive(Context context, Intent intent) {
final String action = intent.getAction();
[...]
} else if (action.equals(Intent.ACTION_SCREEN_OFF)
|| action.equals(Intent.ACTION_DREAMING_STARTED)) {
final long nowElapsed = SystemClock.elapsedRealtime();
final long when = nowElapsed + INACTIVITY_IDLE_THRESHOLD;
mAlarm.setWindow(AlarmManager.ELAPSED_REALTIME_WAKEUP,
when, IDLE_WINDOW_SLOP, mIdleTriggerIntent);
}
[...]
64. @Override
public void onReceive(Context context, Intent intent) {
final String action = intent.getAction();
if (action.equals(Intent.ACTION_SCREEN_ON)
|| action.equals(Intent.ACTION_DREAMING_STOPPED)) {
// possible transition to not-idle
if (mIdle) {
[...]
mAlarm.cancel(mIdleTriggerIntent);
mIdle = false;
reportNewIdleState(mIdle);
}
[...]
65. @Override
public void onReceive(Context context, Intent intent) {
final String action = intent.getAction();
[...]
} else if (action.equals(ACTION_TRIGGER_IDLE)) {
// idle time starts now
if (!mIdle) {
[...]
mIdle = true;
reportNewIdleState(mIdle);
}
}
}
66. The “idle” state algorithm
● time is not a factor
at night
● sensors not used
lying next to the bed
Android Doze to the rescue?
67. The “idle” state algorithm
● display the only factor
how long is being turned off
● not tuned per user
same for everyone
not based on our own behaviour
68. The “idle” state algorithm
● random 71 minutes
or maybe there is some magic here?
69. Takeaways
● don’t be afraid to look at the code
not a rocket science there
can cure from inferiority complex
● write code to get better
it always sucks with the first version
gets better which each commit or PR