Defining the Data Model

The premise of our app is simple, show page from a story and 0:00 present the user with a set of choices. 0:03 But implementing it can be tricky depending on how we want to structure 0:05 things. 0:10 Let's set a few guidelines to keep things simple. 0:10 Number one, let's keep it short. 0:13 Number two, each page will have an image and some text. 0:15 They will all have the exact same format. 0:18 And number three, there will be only two choices per page. 0:20 This will mean we have the same number of buttons at the bottom of each screen. 0:24 Because our readers will be able to take multiple paths through our story, 0:27 I find it really helpful to map it out visually. 0:31 Like a flowchart or more specifically a finite-state machine, which we have here. 0:33 Let's start with an initial state which maps to when the user first starts 0:38 our app. 0:42 Now if this were a regular story, 0:42 the reader would read through these pages consecutively all the way to the end. 0:43 Each page would be a new circle or 0:47 state of this diagram and the final state is the last page or the end of the book. 0:49 In our case, after the user enters their name on the first screen, 0:54 there will be a page one which will have two choices. 0:57 With either choice, the next page will also have two choices. 1:00 If we kept this up, even after a few levels we would have tones of pairs and 1:03 a huge story with lots of outcomes. 1:07 But we can't connect two existing pages, we don't need a new page in the story for 1:09 each choice. 1:13 Sometimes we'll have loops or multiple paths to the same point in the story. 1:14 Anyhow I wrote this story for this app with just a few pages and choices. 1:18 But the way we implement it will allow you to make your story as long and 1:21 as complex as you'd like. 1:25 Here's the map I ended up with. 1:26 I had a few basic ideas and 1:28 then plotted them in a diagram like this to understand the structure. 1:29 We can now use the structure to set up our data model objects and 1:32 use them in a story activity. 1:35 Note that I changed the first page to start at 0 instead of 1. 1:37 Since erase and other collections in Java start at 0, 1:40 this will help us map useful numbers. 1:43 With this model in mind, should we just create a new activity and 1:45 layout for each page in the story? 1:48 Well, your code spidey-sense should be firing at this point. 1:50 We could do it for a small story like this. 1:53 But remember that we said all our story pages will have the exact same structure. 1:55 Even this small story would be a lot of repetition and 2:00 it would quickly become unmanageable for larger stories. 2:02 I actually tried this out. 2:05 I prototyped it with a new activity for every page in the story and 2:07 I found myself typing a lot of the same code over and over again. 2:10 So I scrapped the prototype and came back to this method where I will use the same 2:14 activity and just change the views inside it for each page in the story. 2:18 That's actually a good lesson. 2:23 You shouldn't be afraid to try things out and throw that code away. 2:24 Not all code that you write will be perfect and the best way 2:27 to figure out if something is going to work or not is to go ahead and try it out. 2:30 So let's use one activity with one layout file to display each page of the story. 2:33 We'll just reload the data on the screen based on the choice that the user makes. 2:38 Do you see how the MVP pattern is at work here? 2:42 The layout is the view, the page of the story is the model, and 2:45 the presenter, the activity, will update the model and refresh the view. 2:48 Beautiful. 2:53