Делегаты По сравнению с Уведомлениями в iPhoneOS

К делегатам немного сложно привыкнуть, но я думаю, что это лучшая практика, и, как и Apple, они просто работают .

Я всегда использую официальную декларацию протокола. На мой взгляд, это немного более логично, и это очень ясно в коде. Я предлагаю использовать UIView для изменения ваших параметров вместо контроллера. Я всегда использую один главный контроллер и имею множество подклассов UIView, которыми может управлять один контроллер. (Однако вы можете изменить следующий код для контроллера, , если вам действительно нужен контроллер вместо обычного представления.) Сделайте так, чтобы в заголовочном файле дочернего представления он выглядел так:

// ChildView.h
#import <UIKit/UIKit.h>

@protocol ChildViewDelegate; // tells the compiler that there will be a protocol definition later

@interface ChildViewController : UIView {
    id <ChildViewDelegate> delegate;
    // more stuff
}

// properties and class/instance methods

@end

@protocol ChildViewDelegate // this is the formal definition

- (void)childView:(ChildView *)c willDismissWithButtonIndex:(NSInteger)i; // change the part after (ChildView *)c to reflect the chosen options

@end

Метод между @protocol и вторым @end может быть вызван где-нибудь в реализация ChildView, и тогда ваш контроллер корневого представления может быть делегатом, который получает «уведомление».

Файл .m должен быть таким:

// ChildView.m
#import "ChildView.h"

@implementation ChildView

- (id)initWithDelegate:(id<ChildViewDelegate>)del { // make this whatever you want
    if (self = [super initWithFrame:CGRect(0, 0, 50, 50)]) { // if frame is a parameter for the init method, you can make that here, your choice
        delegate = del; // this defines what class listens to the 'notification'
    }
    return self;
}

// other methods

// example: a method that will remove the subview

- (void)dismiss {
    // tell the delegate (listener) that you're about to dismiss this view
    [delegate childView:self willDismissWithButtonIndex:3];
    [self removeFromSuperView];
}

@end

Тогда файл .h корневого контроллера представления будет включать следующий код :

// RootViewController.h
#import "ChildView.h"

@interface RootViewController : UIViewController <ChildViewDelegate> {
    // stuff
}

// stuff

@end

И файл реализации будет реализовывать метод, определенный в протоколе в ChildView.h, потому что он будет запускаться, когда ChildView требует его запуска. В этом методе поместите то, что происходит, когда вы получите уведомление.

Как насчет

return i > j? (i > k? i: k): (j > k? j: k);

двух сравнений, без использования временных временных переменных стека...

Метод доступа attr _ можно использовать для создания виртуального атрибута и установки этого атрибута как части действия создания.

В этом случае нет необходимости использовать делегирование или уведомление, поскольку нет необходимости напрямую обмениваться мнениями. Как сказал gerry3, необходимо изменить саму модель данных, а затем позволить всем остальным представлениям отреагировать на это изменение.

Модель данных должна быть независимым объектом, к которому имеют доступ все контроллеры представлений. (Ленивый способ - парковать его как атрибут делегата приложения.) Когда пользователь вносит изменения в ракурс A, контроллер ракурса A записывает эти изменения в модель данных. Затем при каждом открытии ракурсов B-Z их контроллеры считывают модель данных и соответствующим образом конфигурируют ракурсы.

В этом пути ни представления, ни их контроллеры не должны быть осведомлены друг о друге, и все изменения происходят в одном центральном объекте, поэтому они легко отслеживаются.

Действительно ли необходимо, чтобы контроллер корневого представления знал об изменениях, или только вложенные представления?

Если корневому контроллеру не нужно знать, то то, что настройки посылают уведомления, которые ищут другие представления, кажется мне лучшим ответом, так как это упрощает код. Нет необходимости вводить больше сложностей, чем нужно.

Обычно, если вам нужно обновить пользовательский интерфейс на основе изменения данных в модели, вы должны заставить контроллеры представления наблюдать за соответствующими данными модели и обновлять свои представления при получении уведомления об изменениях.

Я считаю делегирование более формальным и мне нравится различие, которым недавно поделился Питер Хоси:

Разница в том, что делегирование является для одного (и двунаправленного) коммуникации, в то время как уведомления предназначены для многих, однонаправленных коммуникации.

Кроме того, я обнаружил, что (полное) обновление представления в viewWillAppear: работает нормально (но это не лучшее решение, если речь идет о производительности).

Я хотел бы добавить:

объектов, получающих уведомления, могут реагировать только после того, как событие произошел. Это значительный отличие от делегирования. В делегату предоставляется возможность отклонить или изменить операцию, предложенную делегирующий объект. Наблюдая объекты, с другой стороны, не могут непосредственно повлиять на надвигающийся операция.