The premise of our app is simple, show page from a story and

present the user with a set of choices.

But implementing it can be tricky depending on how we want to structure

things.

Let's set a few guidelines to keep things simple.

Number one, let's keep it short.

Number two, each page will have an image and some text.

They will all have the exact same format.

And number three, there will be only two choices per page.

This will mean we have the same number of buttons at the bottom of each screen.

Because our readers will be able to take multiple paths through our story,

I find it really helpful to map it out visually.

Like a flowchart or more specifically a finite-state machine, which we have here.

Let's start with an initial state which maps to when the user first starts

our app.

Now if this were a regular story,

the reader would read through these pages consecutively all the way to the end.

Each page would be a new circle or

state of this diagram and the final state is the last page or the end of the book.

In our case, after the user enters their name on the first screen,

there will be a page one which will have two choices.

With either choice, the next page will also have two choices.

If we kept this up, even after a few levels we would have tones of pairs and

a huge story with lots of outcomes.

But we can't connect two existing pages, we don't need a new page in the story for

each choice.

Sometimes we'll have loops or multiple paths to the same point in the story.

Anyhow I wrote this story for this app with just a few pages and choices.

But the way we implement it will allow you to make your story as long and

as complex as you'd like.

Here's the map I ended up with.

I had a few basic ideas and

then plotted them in a diagram like this to understand the structure.

We can now use the structure to set up our data model objects and

use them in a story activity.

Note that I changed the first page to start at 0 instead of 1.

Since erase and other collections in Java start at 0,

this will help us map useful numbers.

With this model in mind, should we just create a new activity and

layout for each page in the story?

Well, your code spidey-sense should be firing at this point.

We could do it for a small story like this.

But remember that we said all our story pages will have the exact same structure.

Even this small story would be a lot of repetition and

it would quickly become unmanageable for larger stories.

I actually tried this out.

I prototyped it with a new activity for every page in the story and

I found myself typing a lot of the same code over and over again.

So I scrapped the prototype and came back to this method where I will use the same

activity and just change the views inside it for each page in the story.

That's actually a good lesson.

You shouldn't be afraid to try things out and throw that code away.

Not all code that you write will be perfect and the best way

to figure out if something is going to work or not is to go ahead and try it out.

So let's use one activity with one layout file to display each page of the story.

We'll just reload the data on the screen based on the choice that the user makes.

Do you see how the MVP pattern is at work here?

The layout is the view, the page of the story is the model, and

the presenter, the activity, will update the model and refresh the view.

Beautiful.