Learning Presenter First Approach in Android Part 1

This will be the first in a series of posts of me learning both the Presenter first approach and the Android Platform.

In this part of the series I tackle the first chapter on the Code Ranch book doing it with the Presenter First approach (as closely as I can) all the while learning the basic widgets of Android and its setup.

There is an even better or much more idiomatic way of doing the Presenter First in android through this repository by olerass which really drove me to do and learn the approach.

Presenter First is an approach that I wanted to learn for its combination of Test-Driven Development (which I practice often) and of the Model-View-Presenter (A Presentation pattern that I’m familiar with).

Before you actually read this I’ll assume you are familiar with Model-View-Presenter specifically the Passive or Humble View variant and also on the Process of Test-Driven Development, Junit and Mockito. I’ll show you some of  the references that I’ve read :

For Model-View-Presenter:

For the concept of Test-Driven Development:

And for a Walkthrough of how to do T.D.D:

With that I’ll start with what the first chapter’s program is

The application you are going to create is called GeoQuiz. GeoQuiz tests the user’s knowledge of
geography. The user presses True or False to answer the question on screen, and GeoQuiz provides
instant feedback.

My take on the program’s definition is that it:

  • Loads a question on startup
  • Renders the question appropriately
  • User either answers True or False 
  • Show if given answer is correct or incorrect based on the question

Following through the examples I ended up with this code  which is exactly the same as the the one showed in the book in its first chapter.

The big takeaway up to that point was that I was exposed to the view hierarchy in Android through the writing of XML.

As the code stands it didn’t really evaluate if the answer to the question was correct or incorrect. It just Toasts out Correct on pressing the True and Incorrect on the False Buttons.

Taking it up a notch I decided to follow the Presenter First approach to start driving out the design of the code. Before actually writing the code I pictured out a rough design on showing a correct message via a Sequence Diagram.

Since a question was loaded at startup I decided to do this test at the presenter level:

which was passed by this degenerate implementation (Simplest Thing that can possibly pass the test)

Moving Forward I decided to Triangulate (Junit doesn’t have a good way of making parameterized tests unlike Xunit.net for C#) the collaboration between the passing of the Model’s text to the view.

which was passed with this implementation

Right now it can load up a question on startup. The rendering part is something that I can’t really unit-test (following its FIRST definition)  so I’ll leave it out.

For determining if the given answer is correct or incorrect I started with this:

This test is very brittle since this implementation passes for the wrong reason: it calls the showCorrectMessage on creation.

This might be an indication that I was going the wrong way or that I tested one step ahead. In either case I ended up with this test and implementation to force the design to come out

For an incorrect scenario I started out with this:

Doing the simplest thing that can possibly pass the test by calling the showIncorrectMessage() on the onAnswer() method, but it still isn’t the design I’m looking for.

Finally through this last test I was now able to actually see the design that I wanted:

With this the Application can now show a correct message on a correct answer and a incorrect message on a incorrect answer.

I could walk you through the setup on the Android side but I’ll just point you through my github repository for this.

Summary

This was a long post for this week. I mean this approach might be overkill for a simple application like this but seeing as how the book goes on for adding features I think I that this approach makes code more flexible to change because of the unit tests that make it safe for refactoring although its mostly using mocks (which should be used mostly for the boundary of your system) to drive out the design.

Also those who are familiar with Presenter First may notice I have a public API on my presenter when it suggests having none and that it should only communicate through events. That is because this is one of the reifications that I’m familiar with the Model-View-Presenter pattern.

Thank you for reading and Happy Coding.