IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
Mattbrenner
1. A Unified Approach to Callbacks in Android
Matt Brenner – UnME2, Inc.
mbrenner@unme2.com
Droidcon Berlin 2013
2. Background Knowledge
This talk will include discussion of,
threads
Interfaces
callbacks
Observer Design Pattern
and make extensive use of UML.
Don't worry, we'll “fill in” all gaps along the way!
3. A Unified Approach to Callbacks in Android
In Java, callbacks commonly occur within processes:
between threads
to decouple domain / interface (e.g. Observer)
4. “Worker Thread” Callback
public Interface Requester {
public void complete ( ); Requester
} «interface»
public class Mainclass implements Requester { + complete( ) : void
...
public void dosomething (...) {
...
(new Worker (this)).start ();
} Mainclass
public void complete ( ) { + dosomething (...) : void
... + complete( ) : void
} ...
}
public class Worker extends Thread {
private Requester requester_;
Thread
...
public Worker (Requester requester) {
requester_ = requester
}
...
public void run( ) { Worker
...
requester_.complete ( ); + Worker (requester : Requester)
} + run ( ) : void
} ...
6. Android Makes Extensive Use Intents
Intents are used:
for inter-process and inter-Activity comms
to invoke Activities (passing params)
to callback from one Activity to another
(return a result)
7. Activity Callback
(Calling Activity)
public class AnActiviy extends Activity {
static private final int GOTYESNO = 1,
...
public void askyesno( ) {
Intent intent;
...
intent = new Intent (this, ActivityGetyesno.class);
intent.putExtra (“title”, R.string.delete_all_title);
intent.putExtra (“msg”, R.string.delete_all_msg);
startActivityForResult (intent, GOTYESNO);
}
protected void onActivityResult (int id, int result, Intent data) {
if (id == GOTYESNO) {
if (data.hasExtra (“RESULT”)) {
result = data.getExtras( ).getString
(“RESULT”);
if (result.equals (“yes”)) {
...
}
}
}
}
...
}
9. A Bit of a Mess
Multiple callbacks in various forms lead to:
interface “clutter”
multiple callback forms in a single class
Intent syntax is klunky and repetitious
New design pattern to the rescue: Event Consumer (Brenner)
17. public class AnActiviy extends SuperActivity {
static private final int COMPLETE = 1,
UPDATE = 2,
Voila! A Unified Approach to Callbacks: GOTYESNO
= 3;
...
Worker Thread
public void dosomething (...) {
Domain-to-Interface (new Worker (this, COMPLETE)).start ( );
}
Intent-to-Intent public void observe (Domainthing thing) {
thing.addobserver (this, UPDATE);
}
public void asktyesno( ) {
Launcher launcher;
...
lancher = new Launcher (this, GOTYESNO,
R.string.delete_all_title, R.string.delete_all_msg);
launcher.launch (ActivityGetyesnodialog.class);
}
public void event (int eventid, Object data) {
switch (eventid) {
case COMPLETE: // thread-to- thread callbackevent
...
break;
case UPDATE: // domain-to-interface callback
event
...
break;
case GOTYESNO: // intent-to-intent callback event
if (isyes()) {
...
}
break;
}
}
}
18. An Unsatisfying Aspect
I commonly apply Eventconsumer to Activities:
extend Superactivity
implemement event method
It is natural to apply it to ListActivity too:
create SuperListActivity
must duplicate (or delegate) methods similar to those in
SuperActivity