Section 4.2, incremental running

Hi. I’m enjoying the book and have just reached the end of section 4.2, Adding Graphics to Sudoku.

Unlike Chapter 3, this section has a lot of coding but no running of the app because there is always some new reference to a method or class that has yet to be defined.

The amount of new code means that typos are quite likely, so it would be good to have the chance to run the code a few times during section 4.2. Also, it would just make it a little more fun for the reader.

Anyway, with this in mind, I used Eclipse’s Quick Fix feature on the “missing method” errors listed in the Problems view. This generated stubs for the three missing methods in Game. Tried running with these basic stubs and got a force close.

Added some more to the stubs to return non-null and the app is runnable. Here are my dummy methods for Game:

    private int[] getPuzzle(int diff) {
        // TODO Auto-generated method stub
        Log.d(TAG, "getPuzzle()");
        int[] p = new int[81];
        for (int i=0; i < 81; i++){
            p[i] = 1 + (i/9 + i%9)%9;
        }
        return p;
    }

    private void calculateUsedTiles() {
        // TODO Auto-generated method stub
        Log.d(TAG, "calculateUsedTiles()");
    }

    protected String getTileString(int i, int j) {
        // TODO Auto-generated method stub
        Log.d(TAG, "getTileString(" + i + ", " + j + ")");
        String s = Integer.toString(puzzle[i*9 + j]);
        return s;
    }

I’ll continue with this approach in cases where simple missing methods or classes prevent the app running. This also makes for a more realistic development experience for the reader, since this is closer to how an app evolves in the real world.

Onward and upward.

In the first version of the book I left out those methods altogether, because it’s a book on Android and they have nothing to do with Android. I expected people to download and run the code from the zip file. But then I got a lot of feedback from readers who wanted to see every line printed in the book so they could type it in. That’s why in newer editions I put them in section 4.4 “The Rest of the Story”.

To completely eliminate missing method errors I would have to present the code from the bottom up. For example, before I got to the Android stuff I’d have to spend several pages on Sudoku tile calculations and string manipulation and whatnot. That would interrupt the flow of the text so I don’t want to do that, but at this point I’m still trying to think of a better way.

Hi Ed. The stub methods don’t need to have much content, just enough to satisfy the method call and return object.

I was just checking through the errata for the book and saw a comment from Michael Weingarden which makes a similar point.

Here’s part of Michael’s comment: Up until Chapter 4, the book is paced well for a beginner. Chapter 4 is like the bronco that almost bucked me. It would have been nice to have given the reader the chance to run the code a few times throughout the chapter.

I’ve just completed Chapter 4 myself and, even with the use of stub methods and incremental testing, I found it quite gruelling.

Something for a future edition?

Definitely.

Does the emulator actually run with stub methods?

What I did (which was a bit scary but ended up working) was not to turn off error-checking in Eclipse and to create stub methods as I went, sometimes also jumping ahead to where the method was defined. Then when I was done with the chapter and Eclipse didn’t show errors, I figured it was at least consistent. I think I then had to do maybe just some minimal debugging to make it work. But it was indeed a pretty long stretch without verifying in the emulator that things were what they were supposed to be.

I DEFINITELY like putting all of the code in the book rather than just pulling it off of the web. While I didn’t understand a lot of what I was typing as I did it, actually writing it up yourself helps a LOT in the learning process. As noted in one of my problem posts, I changed some minor things along the way just to get a feel for how it works. And after you go through it, you get a pretty decent picture of what an Android program should look like.

Any change I can think of from the way you’re presenting it would make the book longer, but if longer is an option (without sacrificing content), I’d go with an incremental approach that isn’t entirely bottom-up but oriented just toward finished steps. For example with Sudoku: First get code out there that just makes the Sudoku board with grid and let the reader run that. Then add the givens to the board and run that. Then allow the user to enter additional numbers and run that. Finally hints and whatever is left. Then you have smaller runnable steps (which I personally like). But on the downside it would take more pages to get the same result.

I think the book as is does a great job at being “not a tome” but at the same time getting you pretty deep into good Android programming.

I appreciate the feedback. While there is no 4th edition in the works currently, if I do one I’ll certainly take this into consideration.

Hi Marshall Farrier. Just to confirm, yes it works with the stub methods as listed in my initial post to this thread. The functionality is not all there, but you can see the grid drawn. There’s no need to disable Eclipse’s error checking, and I wouldn’t do this except in extreme cases… I like to know what’s going on :)

Ok, thanks.

This will be addressed in the 5th printing (P5.0) of the 3rd edition.

I thought about stub methods but they cause other problems in the book mechanics. So instead of stub methods I enhanced the cross-references so that readers can find the non-graphics methods more readily.

Also I added a paragraph at the beginning of the chapter explaining what’s going on. I hope this will strike a good balance for people who are just reading vs. people who are typing in all the code. It goes something like this:

“Note: To make this chapter easier to read, I’ve gathered all the non-graphics sample code into its own section, [Loose Ends]. For example, that’s where you can find methods for implementing the logic for the Sudoku game and parsing puzzle strings. If your goal is to get the chapter’s final Sudoku example up and running, you’ll need to type in or download that code. Every important method is cross-referenced in the Index. However, if your goal is to read through the material to learn about Android graphics, then you can skip it.”

Hi Ed. Seems a good approach. I look forward to getting the updated eBook. (I have the printed edition too)

One last word for the stubs. I’ve used stubs as I worked through the book, particularly Chapter 4, and I’ve not had any conflicts with the flow of the book, or the later sections where the “full” methods are added. For me, the use of stub methods strikes a good balance in allowing the app to be run more often as development progresses, and before the volume of new untested code gets to great (making it harder to find bugs and typos). I know the book is not meant to be general teaching programming technique but, while this could be seen as straying into that arena, the main reason is to give more opportunity to run the app. As Chapter 4 currently stands, the contrast with Chapter 3 is very marked in this regard.

Sorry to labour the point, but I felt it worth one more try :)

Best regards,
Thomas.

Aside from some tool issues with multiple versions of the same method, as I thought about it I became concerned that if they weren’t careful, readers might become confused and miss the corrected version. Then they would wonder why it wasn’t working right. Also, this would be different from the way I present a skeleton function and then add new lines in other parts of the book.

I appreciate your feedback and I’ll continue to think about ways to improve it in future updates.