Xcode Nav Buttons

You can change the title of the back button and put a rightBarButton on the screen using the following code.

In the – (void)viewDidLoad method, just after [super viewDidLoad]; put this code.


UIBarButtonItem *backButton =
    UIBarButtonItem *backButton =
    [[UIBarButtonItem alloc] initWithTitle: @"Main"
                                     style: UIBarButtonItemStyleBordered
                                    target: nil
                                    action: nil];
    self.navigationItem.backBarButtonItem = backButton;


    UIBarButtonItem *helpButton =
    [[UIBarButtonItem alloc] initWithTitle: @"Help"
                                     style: UIBarButtonItemStylePlain
                                    target: self
                                    action: @selector(goToHelp)];
    self.navigationItem.rightBarButtonItem = helpButton;
    self.navigationItem.rightBarButtonItem.enabled = YES;

If you don’t want a back button use this


[self.navigationItem setHidesBackButton:YES];

Does Objective-C have anything like PHP’s include_once?

The short answer is “That’s not how you do things in iOS”.

You could mimic the code replacement functionality of PHP includes by using #defines. If you wanted to you could write code just like you do in PHP and pull repetitive portions into #defines. Put them into {ProjectName}-Prefix.pch and they will be automatically available to all of your classes.

What you want to do is restructure your code so that it uses the Model-View-Controller pattern. Pull model-related code out of the main view and put it into a series of classes. Same with view-related code. Sometimes that’s all you need to do and sometimes it gets more complicated.

For example, in my quiz titles I have a preference pane where users can choose which category or categories they want to be quizzed on and the degree of difficulty. When the game first initializes I need to set the default preferences in NSUserDefaults. I created a class for the code and invoke it using

PreferencesInitialization *prefs =[[PreferencesInitialization alloc] init];
[prefs initializePreferences];

The code snippet above acts just like a PHP include and runs the code when it is called.

That works fine if the code in question has no interaction with the current view or data. In the quiz game I put scoring buttons at the bottom of the screen in a toolbar. I pulled all of the code out of the view and put it into a class. I call the class like I did above. Except that the class knows nothing about the environment it is running in. So I need to pass _everything_ it needs to know about to it.

self.scoringToolbar = [[ScoringToolbar alloc] initWithScoreKeeper:self.scoreKeeper parentView:self.view];

This is where it gets a bit tricky, it needs to know about the **current instance** of the scoreKeeper (the class that tallies the results) and the current view. In order to place the toolbar at the bottom of the screen scoringToolbar uses the self.view information to calculate positions. All of the self.view calculations are changed to self.parentView.
e.g.

CGSize windowSize = self.parentView.frame.size;

The scoringToolbar is completely self-contained so once it has its initial parameters it runs on its own. The view controller can get information from it by invoking its methods.

The third type of interaction is where the view controller tells the object to do something, say play a sound, and the target tells the view controller when it is done. The way they do that is with the use of delegates. I pulled the recording and playback portion of the game out of the main view and put it into a class. Just like the scoringToolbar it needs to know about the current view.

self.recordPlay = [[RecordPlay alloc] initWithParentView:self.view ];
[self.recordPlay setDelegate:self];

Tell the recordPlay class to play a sound with a playSound method.

[self.recordPlay playWord:targetSnd];

By setting up the view controller as a delegate of recordPlay it can be notified when the sound is finished playing and respond accordingly.

In recordPlay call

[self.delegate soundFinishedPlaying:self.soundToPlay];

This calls the soundFinishedPlaying method in the view controller and it does whatever is appropriate. Like telling the picture class to highlight a picture or the recordPlay class to play the next sound.

Delegates turn out to be key to the Model-View-Controller pattern. In my game, the controller asks the wordList class for a word using a method in wordList. If there aren’t any words, the wordList delegate lets the controller know and the controller launches the preferencesPane. When an picture is clicked on, the pictureView class tells the controller and the controller decides which sound to play. Then it tells the recordPlay class which sound to play.

Classes don’t communicate with each other—in fact they don’t even know about each other. The controller is an intermediary and it tells everyone else what to do.

I suppose this is obvious to someone with an object-oriented background, but it took me a year to figure out. I’ve rewritten my game to use these concepts and its much easier to manage. By swapping out classes I can reuse the basic structure in several similar games.

Hope his helps someone else.