todo.txt

First things first, let's get an image showing on the screen.
No network, no assets, just a basic old bitmap on an ImageView.

Thinking of two approaches.

Option A: Android objects come out of the Presenter object
String resources are processed somewhere before the Presenter and passed out
Images are process somewhere before the Presenter and passed out
We may return a Drawable, which traps some Android API in the Presenter API
But if the goal is for the View layer to be humble we either need a Presenter that returns a Drawable,
Or Option B, some kind of Adapter that takes the Presenter output and returns a Drawable
At this stage, the shape of the code is more unknown and we don't know
whether mixing Android API with Presentation Logic will become cumbersome.
Option A is less objects and less complex, so I vote we go that way and deal with it
when/if coupling rears it's ugly head

Ideally, start specific, then grow abstract.
Returning Drawable outright from our presenter may not be healthy, because it's really not a primitive.
It depends on Android, and many of the most complex of parts of it.
We don't immediately gain value by returning Drawable, not at least until we need to return more than one format of image.
And maybe even then, return less than the full drawable api.
Maybe this starts to shape our own api taking the form of our domain language, and then drawable can render _that_.
"The purpose of abstraction is not to be vague,
but to create a new semantic level in which one can be absolutely precise." — Edsger Dijkstra.

Maybe we should bootstrap testing from real Android code, and "pull up" into higher abstractions
that can run on unit tests rather than instrumented tests.

* Creating the imgur account
* Pulling an image with HttpUrlConnection, right in the MainActivity, and show
  * Extract presentation logic
  * Extract network logic
* Loading scaled image? or caching?