Архитектура приложения iPhone

Жизненный цикл приложения состоит из последовательности событий, возникающих с момента его запуска и до момента завершения. После выбора и нажатия пользователем иконки приложения система запускает его, вызывая функцию main. Инициализация приложения передается UIKit, который загружает пользовательский интерфейс и сканирует цикл его событий. В процессе исполнения цикла событий UIKit координирует доставку событий custom objects и отвечает на команды, отправляемые приложением. После того, как пользователь совершил действие по закрытию приложения, UIKit уведомляет приложение об этом и приступает к завершению процесса. Во время инициализации и завершения UIKit отправляет специальные сообщения к объекту делегата приложения, позволяя ему знать, что происходит. Во время исполнения цикла событий UIKit посылает события к соответствующим обработчикам разработчика.
В приложениях для айфонов функция main используется минимально. В действительности большинство работы выполняет UIApplicationMain. Функция main выполняет всего три вещи: создает autorelease пул, вызывает UIApplicationMain и освобождает autorelease пул. Код функции main приведен ниже:

1. #import <UIKit/UIKit.h>
2. int main(int argc, char *argv[])
3. {
4.     NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
5.     int retVal = UIApplicationMain(argc, argv, nil, nil);
6.     [pool release];
7.     return retVal;
8. }

Autorelease пул используется в управлении памятью. Это механизм Cocoa для отсрочки освобождение объектов, созданных в процессе исполнения блока кода. Функция UIApplicationMain использует четыре параметра для инициализации приложения. Первые два параметра argc и argv являются строками, определяющими принципиальный класс (класс приложения) и класс делегата приложения. Если значение принципиального класса равно nil, UIKit ипользует класс UIApplicationMain. Если класс делегата равен nil, то UIKit считает, что делегатом приложения является один из объектов, загруженных через главный nib-файл приложения (для приложений, построенных с использованием шаблонов Xcode). Т.о. если приложение использует произвольный подкласс UIApplicationMain (что не рекомендуется, но является возможным), то его имя указывается третьим параметром.
Делегат приложения ответственен за управление несколькими критическими системными сообщениями и должен присутствовать в каждом приложении для айфона. Объект может быть экземпляром любого класса, но должен быть совместим с протоколом UIApplicationDelegate. Методы этого протокола определяют перехватчиков событий в жизненном цикле приложения и предоставляют возможность реализовывать произвольное поведение.
Главный nib-file загружается в процессе инициализации приложения. Если информационный список свойств приложения (Info.plist) содержит ключ NSMainNibFile, то объект UIApplication загружает nib-файл, определенный этим ключом. Это единственный nib-файл, который загружается автоматически.
Nib-файл – файл ресурсов, расположенный на диске и хранящий в себе копию одного или нескольких объектов. Главный nib-файл приложения обычно состоит из объекта окна, делегата приложения и возможно одного или нескольких ключевых объектов для управления окном. Загрузка такого файла означает воспроизведение сохраненных в нем объектов в виде реальных объектов памяти, которые приложение сможет использовать. Объекты из этих файлов ничем не отличаются от объектов, созданных программным путем. Однако для пользовательских интерфейсов рекомендуется использовать именно nib-файлы, которые создаются при использовании Interface Builder для проектирования интерфейса, нежели создавать интерфейс приложения программно.
После запуска приложения система создает процесс и главный поток, в котором осуществляется запуск главного исполняющего цикла и настройка обработки событий. После этого цикл постоянно сканирует наличие источников данных для обработки. Когда поступает новое событие, цикл пробуждает исполняющий поток и передает управление обработчику, соответствующему данному событию. После окончания обработки управление возвращается циклу, который начинает обработку следующего события или, в случае его отсутствия, переводит поток в сон. Разработчик может сам переопределить обработку поступающих событий через класс NSRunLop. Поиск обработчика события идет по цепи обработчиков, которая обычно начинается с первичного обработчика. Если он не может обработать событие, то он передает его следующему обработчику в цепи. Сообщение продвигается вверх по цепочке до самого верхнего обработчика, такого как окно, приложение и делегат приложения – пока сообщение не будет обработано. Если обработчик не найден, то событие отбрасывается.
Источник