Staff’s Choice of Native Apps: Evil Hangman

http://developer.apple.com/library/mac/referencelibrary/GettingStarted/Learning_Objective-C_A_Primer/

You’ll find that it’s a pretty quick read and hopefully whets your appetite for a bit more detail.

http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html

This one’s a few chapters, so be sure to click through to each by clicking Next in the bottom-right corner of most every page or by clicking through to each via the Table of Contents in the site’s top-left corner.

Odds are you won’t retain everything you read. But not to worry; it’ll start to sink in once you get your hands dirty with code of your own.

http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

Try to keep those guidelines in mind as you begin to write code of your own. We won’t expect strict adherence to Apple’s guidelines, so long as your own style is clean and consistent, but might as well familiarize yourself with some best practices.

–––––––

Guess a letter, and I’ll tell you where, if anywhere, it appears in the word. You can guess incorrectly up to, oh, six times. If you can figure out the word, you win; if you can’t (and you’re out of guesses), I win. Ready? Okay, guess a letter.

A, you say? You are so smart. That letter appears twice:

–A–––A–

Recognize the word now? No? Not to worry, you still have six chances left, since your first guess was a good one. Guess again.

E, you say? Nope, sorry, not so smart after all. You’ve now used up one of your six chances, so you have five chances left. Guess again.

I, you say? Nope! You have four chances left. Guess again.

Z, you say? Nope! You now have three chances left. Guess again.

N, you say? Nice! That letter also appears twice:

–AN––AN

You still have three chances left. Guess again.

E, you say? I’ll pretend I didn’t hear that. You guessed that already! You still have three chances left. Guess again.

H, you say? Nice! That letter appears once:

HAN––AN

Recognize the word yet? G, you say? M, you say? That’s right! It’s HANGMAN!

Wait for it…

Evil Hangman.

Put more simply, the computer constantly tries to dodge the user’s guesses by changing the word it’s (supposedly) thinking of. Pretty evil, huh? The funny thing is most humans wouldn’t catch on to this scheme. They’d instead conclude they’re pretty bad at Hangman. Mwah hah hah.

Suffice it to say that the challenge ahead if you is to implement…

Wait for it…

Evil Hangman.

----, which contains BOAR and DUCK
-E--, which contains BEAR
-EE-, which contains DEER
---E, which contains HARE

Note that HARE is not in the same equivalence class as BEAR. Even though both have just one E, each’s E is in a different location. If the computer is forced to admit that the word that it’s "thinking of" contains an E (because it just so happens to have discarded all words that lack E in response to the user’s past guesses), it will be forced to announce (and thus commit to) that letter’s location.

So, back to our story: the user has guessed E. What should the computer now do? Well, it could certainly declare that the word it’s "thinking of" does not contain E, the implication of which is that the list of five words becomes two (BOAR and DUCK). That does feel optimal: armed with two words, the computer might still have a chance to "change its mind" yet again later. Then again, DUCK seems pretty easy to guess, whereas most people might not even think of HARE. On the other hand, I don’t remember the last time I used BOAR in a sentence. But let’s keep it simple: you may assume that the computer will always react to a user’s guess by whittling its list down to the largest equivalence class, with pseudorandomness breaking any ties.

Realize, though, that the largest equivalence class might not always correspond to ----. For instance, suppose that the user had guessed R instead of E. The equivalence classes would thus be as follows:

----, which contains DUCK
---R, which contains BEAR, BOAR, and DEER
--R-, which contains HARE

In this case, the computer should go ahead and admit that the word that it’s "thinking of" contains R at its end, since that leaves three possible words (BEAR, BOAR, and DEER) and thus the maximum amount of maneuverability down the road in reaction to subsequent guesses. Of course, if the user has never heard of a DUCK, then ---- could very well be a superior strategy. But, again, lest you drive yourself nuts with overanalysis, you may assume that the largest equivalence class is optimal, even though it might not be in reality.

Indeed, that strategy might sometimes backfire, at least in a sense. Suppose that, in a new version of the story at hand, there are only three four-letter words in the English language: BOAR, DEER, and HARE. Suppose now that the user guesses E. In this case, our equivalence classes are:

----, which contains BOAR
-EE-, which contains DEER
---E, which contains HARE

Because each has one word, these classes are, of course, of the same size. But if we happen to select -EE- pseudorandomly, thereby whittling our list down to just DEER, we’ll have revealed to the user two of the word’s letters, whereas we could have revealed zero (had we selected ---- instead) or one (had we selected ---E instead). But, again, that’s okay. You are welcome, but not required, to implement a more sophisticated algorithm than that prescribed here; just make clear in some comments how yours happens to work.

As for how to divide a list of words into equivalence classes programmatically, well, we’ll leave that as a challenge for you!

Launch Xcode and select File > New > Project…. When prompted to choose a template, select Application under iOS (if not selected already), then select Utility Application. Then click Next.

On the screen that appears:

Choose a location for the project when prompted, check the box to create a local git repository if you’d like, then click Create.

With Hangman.xcodeproj open in Xcode, go ahead and expand each of the triangles at left (except for UIKit.framework, Foundation.framework, CoreGraphics.framework, and SenTesting.framework), and you should see AppDelegate.{h,m}, MainViewController.{h,m,xib}, and FlipsideViewController.{h,m,xib} among their contents. We’ll take a tour through each of those files, but first a quick demo. Ensure that Hangman > iPhone 6.1 Simulator is selected in the drop-down to the right of the Run button in Xcode’s top-left corner. Then click Run (or hit ⌘-R on your keyboard). If all goes well, the iOS Simulator should launch with this app. How fun!

Okay, it doesn’t do all that much yet, but do click that ⓘ button in the app’s bottom-right corner. Notice how the app flips around to its flipside. Well that’s kind of neat. Click Done in the flipside’s top-left corner, and you should be returned to the front side. It’s okay if you’d like to do that again.

Anyhow, once ready for that tour of the code, quit iOS Simulator, return to Xcode, and open up AppDelegate.h. Notice how this file declares a class called AppDelegate, which implements a protocol called UIApplicationDelegate. That’s good, because it’s to an object of that class that main (in main.m) will ultimately delegate control. That class is implemented in AppDelegate.m, most of whose methods are just stubs with comments, except for application:didFinishLaunchWithOptions:.

Now open up MainViewController.xib. Ah, there’s part of the app’s UI. Indeed, there’s that ⓘ button. If you see two cubes and one square to the left of the graph paper in Xcode’s middle, click the little arrow in the circle in the graph paper’s bottom-left corner. Then click File’s Owner under Placeholders. Can you guess who the owner of this nib will be? Open Xcode’s Identity Inspector to confirm or deny your prediction, as by clicking the fourth icon from the right below View in Xcode’s top-right corner. Yup, this nib belongs to an instantiation of the MainViewController class.

Now click View under Objects (which itself is below Placeholders). Notice that this object’s class is UIView, and it looks like it will fill an iPhone’s whole screen. To confirm as much, open Xcode’s Attributes Inspector, as by clicking the third icon from the right below View in Xcode’s top-right corner, and change Background to something other than gray. (You may need to click the graph paper to see the change.)

Now open up MainViewController.h, which declares the class that owns the nib you just closed. Notice how MainViewController descends from UIViewController. That’s handy, because UIViewController comes with a whole lot of features, per the UIViewController Class Reference:

http://developer.apple.com/library/ios/documentation/uikit/reference/UIViewController_Class/Reference/Reference.html

Notice, too, that MainViewController implements a protocol called FlipsideViewControllerDelegate. (It turns out that protocol is defined in FlipsideViewController.h, but more on that in a moment.) Notice that MainViewController has one instance method (showInfo:), but no instance variables.

Now open up MainViewController.m. Hm, lots more in this file. Let’s look at each method in turn. Defined first are viewDidLoad and didReceiveMemoryWarning, both of which are documented in that UIViewController Class Reference. Also defined in MainViewController.m is flipsideViewControllerDidFinish:, which belongs to that protocol called FlipsideViewController, but more on that in just another moment. Last up is showInfo:, whose declaration was in MainViewController.h. Notice how this method allocates a FlipsideViewController, thereafter initializing it with FlipsideViewController.xib. It then defines itself as the delegate for the flipside’s controller, sets the transition from front side to flipside, and presents that flipside.

Alright, almost done with the tour. Open up FlipsideViewController.xib. Ah, there’s the flipside’s UI. If you ctrl- or right-click File’s Owner, you’ll see how this nib’s owner (a FlipsideViewController) is wired up to a view. You’ll also see how that Done button is wired to a method (i.e., UIAction) called done:. If you expand the triangle next to View (and, in turn, everything below), you’ll see how the flipside’s navigation bar and title relate to that button. In fact, if you ctrl- or right-click Bar Button Item – Done, you’ll see that same wiring in reverse.

Okay, now open up FlipsideViewController.h. Not only does this file declare a class called FlipsideViewController (which descends from UIViewController), it declares a property called delegate, which must apparently point to an object (implied by id) that implements the protocol called FlipsideViewControllerDelegate. It also declares that instance method called done:. And, as promised, it declares that protocol, which apparently prescribes a method called flipsideViewControllerDidFinish:. The implication, of course, is that any class that implements FlipsideViewControllerDelegate (e.g., MainViewController) should implement a method called flipsideViewControllerDidFinish:. Just as we’ve seen!

Finally, open up FlipsideViewController.m. In here are some stubs, just like those we saw in MainViewController.m. But this file also implements done:, whose sole line of code apparently informs the flipside’s delegate (i.e., a MainViewController object) when the flipside is done flipping back.

Phew, time for a break.

http://cdn.cs76.net/2013/summer/projects/staff-ios/words.plist?download

and then drag words.plist into into that Supporting Files group within Xcode. When prompted to choose options for adding the file, check Copy items into destination group’s folder (if needed), ensure that Hangman is checked to the right of Add to targets, and then click Finish. (Since words.plist isn’t a folder, it doesn’t matter what’s selected next to Folders in that window.) You should now see words.plist among your app’s Supporting Files. Click it, and you’ll see a huge array of English words.

Alright, that’s it! It’s time to delegate control of this project to you! (See what we did there?)