Эффективное использование Interface Builder

Question

Я новичок в iPhone и цель c. Я часами часами читал документы и пытался понять, как все работает. У меня RTFM или, по крайней мере, я нахожусь в процессе.

Моя основная проблема заключается в том, что я хочу понять, как указать, куда передается событие, и единственный способ, которым я смог это сделать, - указать делегатов, но я уверен, что в IB есть более простой / быстрый способ.

Итак, пример. Допустим, у меня есть 20 различных представлений и контроллеров представления и один MyAppDelegate. Я хочу иметь возможность создавать все эти различные Xib-файлы в IB и добавлять как можно больше кнопок и текстовых полей и все такое, а затем указывать, что все они вызывают какое-то событие в объекте MyAppDelegate. Для этого я добавил объект MyAppDelegate в каждый контроллер представления в представлении списка IB. Затем я создал метод IBAction в MyAppDelegate в XCode и вернулся к IB и связал все события с объектом MyAppDelegate в каждом файле Xib.

Однако, когда я попытался запустить его, он просто упал с исключением из-за плохого чтения.

Я предполагаю, что каждый файл Xib помещает указатель объекта MyAppDelegate, который не имеет никакого отношения к возможному адресу MyAppDelegate, который фактически будет создан во время выполнения.

Так что мой вопрос ... как я могу это сделать? !!!

Answer 1

Если вы создаете экземпляр MyAppDelegate в каждом файле пера, то да, в итоге вы получите много разных экземпляров класса, когда все пера загружаются. Делегат приложения не определяется классом или даже протоколом, а скорее является объектом, на который указывает свойство delegate экземпляра приложения. Чтобы найти истинного делегата приложения, вы должны запросить у самого объекта приложения его делегат

Вы должны сделать так, чтобы все ваши контроллеры представления происходили из родительского класса контроллера представления, который имеет свойство appDelegate. Реализуйте что-то вроде этого:

#import "MyAppDelegateClass.h"

@interface ViewControllerBaseClass :UIViewController {
    MyAppDelegateClass *appDelegate;
}
@property(nonatomic, retain)  *appDelegate;

@end

@implementation ViewControllerBaseClass
@synthesize appDelegate;

-(MyAppDelegateClass *) appDelegate{
    self.appDelegate=(MyAppDelegateClass *)[[UIApplication sharedInstance] delegate];
    return appDelegate;
}
@end

Когда контроллеру представления требуется делегат приложения, он просто вызывает self.appDelegate. Если вы хотите получить доступ к атрибуту делегата приложения, используйте self.appDelegate.attributeName.

Важно то, что вы запрашиваете у приложения конкретный экземпляр делегата во время выполнения. Вы не можете сделать это из файла пера.

Answer 2

Мне не совсем понятно, что именно вы пытаетесь сделать, но, вероятно, это плохая идея. В каждом приложении должен быть только один делегат приложения, и он должен учитывать поведение всего приложения. Как правило, делегат приложения инициализирует корневые контроллеры представления и отображает их, но не более того (кроме обработки таких вещей, как открытие и сохранение источников данных).

Контроллеры представления (подклассы UIViewController) должны взаимодействовать с XIB. Наличие специфичного для представления поведения в контроллерах представления делает приложение более простым в управлении и обслуживании. Как правило, должно быть 0 или 1 XIB на контроллер представления (более сложный). Вы настраиваете взаимодействие с представлениями, используя шаблон Target / Action с IBOutlets и IBActions (полное руководство см. здесь ). Обычно плохая идея делать контроллеры представления или XIB зависимыми от делегата приложения (поскольку уменьшение зависимостей снова облегчает управление кодом).

Answer 3

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