The difficulty I foresaw in this undertaking was a graphical data structure which displays the state of the game board. We didn’t want to implement a heavy game engine for such a simple game, and we didn’t want to make the user interface overly complex. Thanks to the GridView class from the Android API, we can create the illusion of having a board while making use of the already existing onItemClicked method which has as a parameter the position (as an index on the grid) of the user’s finger which touched the View. This is most helpful as it alleviates the extraneous arithmetic involved in determining the index from a MotionEvent alone.
The graphics are relatively simple. I created the players’ tiles in Adobe Illustrator using rounded rectangle paths with no stroke and circular gradient fills of red and blue. Nothing impressive, just something to say “I dominate this spot.” Using the ImageAdapter class (custom subclass of BaseAdapter from the above tutorial) which has an array of Integer references to drawables, I used a less colorful tile to indicate which spaces are free for the current player. The images in the ImageAdapter’s Integer array map to specific indices on the GridView. Using the OnItemClickListener in the DomineeringActivity, we can alter the cells in the GridView using the position parameter of OnItemClick and a pointer to the ImageAdapter in the GridView. After altering the underlying map, the adapter is notified that its data set changed and is refreshed accordingly.
The problem with all of this is justifying the presence of an additional object (Domineering object) which contains an additional copy of the state of the game already described by the map contained in the ImageAdapter class. The only additional functionality required is a way to keep track of the players’ turns (which is easily done with an integer % 2). So Dr. Goadrich’s idea was to replace the array of resource IDs inside the ImageAdapter with the array holding the state of the board inside the Domineering object and use an if-statement to set the appropriate tile color. He also did away with my colored distinction between vertical and horizontal using red and blue tiles. All the players’ tiles are blue now.
I had to slightly augment Dr. Drake’s code in this application by adding a few accessor methods. isCovered(int row, int column) returns as a boolean whether or not the space at (row, column) is covered, getPlayer() returns the player of the current turn as a boolean, and nextPlayer() sets player equal to !player. I also brought the player variable into class-wide scope so that other methods besides play() could change whose turn it is.
The last thing I did was include an options menu that displays help options or lets the user clear the board and start a new game. We do this with a couple of Android method overrides, namely, onCreateOptionsMenu(Menu menu) and onOptionsItemSelected(MenuItem item). The first allows us to inflate the options menu which we defined elsewhere in an XML file, and the second allows us to react to the selection of an item on said menu. The layout of the XML file is relatively simple. The root element is a menu, and each entry between those tags is a menu-item which has an ID, an icon, a title, and a boolean that allows us to select the item once the list is displayed.
The icon for this game is just a 3×3 board with a simple case where vertical wins. If you’ll notice, however, the colors are arranged according to 2/3-rule. 2 blue for 1 tan column, then 2 blue for 1 tan in the bottom row. 2/3 always makes for a much more balanced image, as odd as that sounds.