Am I properly using delegation? If not, how should I be doing this?

Question

So I have taken the plunge into Objective-C programming for iOS development. I have a little app that I am working on, nothing special, but something to help teach me the ropes. The problem I am having is as follows:

Currently, I have two classes. The first being

ViewController

and the second being one that I created myself called

UserDecision

The View controller shows what is on screen, and UserDecisions currently takes the information from buttons pressed on screen, and performs the proper logic on it while working with my model class. My issue is, that I have an update UI method in UserDecision which needs to update the button properties (text, visibility, etc.) in ViewController if certain events take place. Because of this, I can't user an instance of ViewController because I won't be able to access the buttons on screen. So for this I created a delegate system:

@protocol updateUIDelegate <NSObject>

-(void)hideAll;
-(void)makeBackVisible;
-(void)updateOutput:(NSString *)output;
-(void)updateChoices:(NSString *)choices;
-(void)updateTrueButton:(NSString *)trueString;
-(void)updateFalseButton:(NSString *)falseString;
-(void)removeChoiceFromArray;

@end

The above protocol is defined in UserDecision.h, and then I assigned my ViewController as my delegate:

@interface ViewController : UIViewController <updateUIDelegate>;

And then I flush out said methods in my ViewController.m:

#pragma - updateUIDelegates -

//Called when the last screen is displayed
-(void)hideAll{
    [_trueButton setHidden:true];
    [_falseButton setHidden:true];
    [_choicesText setHidden:true];
    [_backButton setHidden:true];
    [_resetButton setHidden:false];
}

//Makes back button visible
-(void)makeBackVisible{
    [_backButton setHidden:false];
}

//Updates the text on the false button
-(void)updateFalseButton:(NSString *)falseString{
    [_falseButton setTitle:falseString forState:UIControlStateNormal];
}

//Updates the text on the true button
-(void)updateTrueButton:(NSString *)trueString{
    [_trueButton setTitle:trueString forState:UIControlStateNormal];
}

//Updates the output text box
-(void)updateOutput:(NSString *)output{
    [_outputText setText:output];
}

//Updates the choices textbox
-(void)updateChoices:(NSString *)choices{
    if(!choicesArray){
        choicesArray = [[NSMutableArray alloc] initWithCapacity:4];
    }
    //If this is the first button press, add string to array and display
    if([_choicesText.text isEqualToString:@""]){
        [choicesArray addObject:choices];
        _choicesText.text = [NSString stringWithFormat:@"%@", choices];
    }
    //Otherwise, add the new string to the array, and print the array
    //using a comma as a way to concatinate the string and get rid of
    //the ugly look of printing out an array.
    else{
        [choicesArray addObject:choices];
        [_choicesText setText:[NSString stringWithFormat:@"%@",[choicesArray componentsJoinedByString:@", "]]];
    }
}

//Removes the last choice from the array
-(void)removeChoiceFromArray{
    [choicesArray removeLastObject];
    [_choicesText setText:[NSString stringWithFormat:@"%@", [choicesArray componentsJoinedByString:@","]]];

}

This allows me to call theses methods by sending them as a message to self.delegate in my UserDecision class when needed.

This is my current setup. My issue has become that I want to create a modal seque view that pops up at the end (after a user presses a button to bring up the view), and which can be dismissed afterward. The problem I have is that this view, from the reading and research I have done online, can only be dismissed through delegation, unless I want things to get nasty. Now, I tried to implement this information in my class, but then I read that a class can only be a delegate to one other class. And since my ViewController(which is my main window) is already a delegate of my UserDecision class, I can't make it a delegate of the new View I have created, and thus can't dismiss the view. So, I am here to ask for your help. How can I go about solving this issue?

Also, for more of my code, should you want to have a look, here is a link to my gitHub: https://github.com/Aghassi/Xcode/tree/master/Bubble%20Tea%20Choice/Bubble%20Tea%20Choice

Answer 1

COMMUNICATION PATTERNS

Delegation is one of the communication patterns that more or less loosely coupled objects use to communicate each other. iOS Framework provides the following patterns: KVO, Notification, Delegation, Block, Target-Action.

In general, there are cases where the choice comes down to a matter of taste. However, there are many cases that are pretty clear cut.

It's also important to note that the use of each of this patterns results in a certain level of coupling among objects involved into the communication process.

Let's focus now on Delegation, Block, Target-Action.

DELEGATION

Level of coupling (proportional to the level of mutual ignorance) : loose

It allows us to customize an object’s behaviour (decoration) and to be notified about certain events (callback). In this case, the coupling is pretty loose, because the sender only knows that its delegate conforms to a certain protocol.

Since a delegate protocol can define arbitrary methods, you can model the communication exactly to your needs. You can hand over payloads in the form of method arguments, and the delegate can even respond in terms of the delegate method’s return value. Delegation is a very flexible and straightforward way to establish some sort of blind communication between two object that should be loosely coupled for design reason. Let's think to the communication mechanism between a tableview and its dataSource delegate.

Conversely, if two objects are that tightly coupled to each other that one cannot function without the other, there’s no need to define a delegate protocol (use composition instead). In these cases, the objects can know of the other’s type and talk to each other directly. Two modern examples of this are UICollectionViewLayout and NSURLSessionConfiguration.

TARGET-ACTION

Level of coupling : very loose

Target-Action is the typical pattern used to send messages in response to user-interface events. Both UIControl on iOS and NSControl/NSCell on the Mac have support for this pattern. Target-Action establishes a very loose coupling between the sender and the recipient of the message. The recipient of the message doesn’t know about the sender, and even the sender doesn’t have to know up front what the recipient will be. In case the target is nil, the action will goes up the responder chain until it finds an object that responds to it. On iOS, each control can even be associated with multiple target-action pairs.

A limitation of target-action-based communication is that the messages sent cannot carry any custom payloads. On the Mac action methods always receive the sender as first argument. On iOS they optionally receive the sender and the event that triggered the action as arguments. But beyond that, there is no way to have a control send other objects with the action message.

BLOCK

Blocks are usually used to pass to an object a behaviour to be executed before its lifecycle end. Besides, they can also substitute delegates with a caveat relevant to the potential creation of retain cycle.

self.tableView.didSelectRowAtIndexPath = ^(NSIndexPath *indexPath) { 
    ...
    [self.tableView reloadData];
    ...
}

In this case the sender retain the table view whose selection block retain the sender so we'd better use delegation pattern.

An example in which block communication shines:

self.operationQueue = [[NSOperationQueue alloc] init]
Operation *operation = [[Operation alloc] init];
operation.completionBlock = ^{
    [self finishedOperation]
}
[operationQueue addOperation:operation];

There's a retain cycle in the above code as well, but once the queue removes the operation, the retain cycle is broken.

Blocks are a very good fit if a message we call has to send back a one-off response that is specific to this method call, because then we can break potential retain cycles. Additionally, if it helps readability to have the code processing the message together with the message call, it’s hard to argue against the use of blocks. Along these lines, a very common use case of blocks are completion handlers, error handlers, and the like.

A CHART HELPING US TO MAKE THE RIGHT CHOICE

source: objc.io

In your specific case, I'd use the target-action communication pattern to dismiss the presented modal view controller.

For example,

 ModalViewController *modalViewController = [[ModalViewController alloc] init];
 [self presentViewController:modalViewController animated:YES completion:^{
    [modalViewController.closeButton addTarget:self action:@selector(dismissModalViewControllerAnimated:)
                              forControlEvents:UIControlEventTouchUpInside];
}];

Answer 2

I believe you want to display a modal view from your ViewController. Let the the modal view be managed by say ViewController2. In ViewController2.h declare a protocol of ViewController2

@protocol viewController2Delegate 

-(void)dismissViewController2;

@end

Now make ViewController implement this protocol

@interface ViewController : UIViewController <updateUIDelegate,viewController2Delegate>

Add the method to the ViewController.m

-(void)dismissViewController2
{
     [self dismissViewControllerAnimated:YES completion:nil];
}

Now whenever you push a modal view(managed by ViewController2) from ViewController you set the delegate to self. Your ViewController.m code might look like this

ViewController2 *objViewController2 = [[ViewController2 alloc]init];
objViewController2.delegate = self;
[self presentViewController:objViewController2 animated:YES completion:nil];

Hope this solves your problem

Answer 3

It is possible for a viewController to dismiss itself. Just hook up a dismiss button to a function that calls something like:

[self.presentingViewController dismissViewControllerAnimated:YES];

or

[self.navigationController popViewControllerAnimated:YES];

Dismissal can be done with a delegate pattern but it is not required for everything.

Answer 4

You viewController class can be a delegate of multiple objects so it should be able to dismiss the modal view. The only issue is if its a delegate of multiple objects of the same class you may need to check which object is calling it.

Look at the tableView delegate methods as an example, the tableView calls them passing itself as the first parameter.

To dismiss a custom modal view you would define a different protocol anyway so there would be no problem with calling the same method.

See example below:

@protocol OSImageViewControllerProtocol <NSObject>

- (void)dismissImageViewer;

@end

@implementation OSImageViewController

- (void)loadView
{   //LOG(@"loadView called");
    scrollView = [[ImageScrollView alloc] init];

    scrollView.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;

    UITapGestureRecognizer *doubleTapRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(scrollViewDoubleTapped:)];
    doubleTapRecognizer.numberOfTapsRequired = 2;
    doubleTapRecognizer.numberOfTouchesRequired = 1;
    [scrollView addGestureRecognizer:doubleTapRecognizer];

    self.view = scrollView;
}

- (BOOL)prefersStatusBarHidden {
    return NO;
}

- (void)scrollViewDoubleTapped:(UITapGestureRecognizer*)recognizer {
    //LOG(@"scrollViewDoubleTapped called");
    [self.delegate dismissImageViewer];
}

@end


@implementation ViewController

-(void)browseImage:(UIImage*)image
{

    OSImageViewController *_imageViewerController = [[OSImageViewController alloc] init];
    UIImage *img = [[UIImage alloc] initWithData:UIImagePNGRepresentation(image)];

    _imageViewerController.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;
    _imageViewerController.modalPresentationStyle = UIModalPresentationFullScreen;
    _imageViewerController.delegate = self;
    [self presentViewController:_imageViewerController animated:YES completion:^(void){
        [_imageViewerController setImage:img];

    }];

}
- (void)dismissImageViewer {
    [self dismissViewControllerAnimated:YES completion:nil];
}

@end

Answer 5

I read that a class can only be a delegate to one other class. And since my ViewController(which is my main window) is already a delegate of my UserDecision class, I can't make it a delegate of the new View I have created

I don't believe that's true. You can make ViewController implement many different protocols, therefore being delegates to different classes/objects.

For example: (UITableViewDelegate and UITextViewDelegate can both be implemented on the same ViewController for 2 separate objects (UITextView and UITableView).

As for using delegation to close modal windows, another option is to use blocks as well.