Определение функциональности в коде

В данном случае файл MainWindow. xib действительно содержит один "интересный" контроллер представления, и его представление загружается из внешнего nib-файла; все остальные контроллеры представлений являются либо контроллерами табличных представлений (которые создают собственные таблицы автоматически), либо контроллерами контейнерных представлений (например, UlSplitViewController и UINavigationController), которые вообще не отображают никакого редактируемого представления.

Итак, в файле MainWindow.xib содержится определение того, как взаимосвязаны между собой различные контроллеры приложения. Как и в большинстве случаев, использование этого nib-файла позволяет обойтись без написания объемного кода, что само по себе приятно. По желанию вы можете изучить все аспекты конфигурации в коде, но, что касается данного примера, мы ограничимся лишь теми строками кода, которые были предоставлены средой разработки Xcode.

Одна из основных причин хранить взаимосвязи контроллеров представлений в nib-файле состоит в том, что он не перегружает наш исходный код данными о конфигурации, которые ему не нужны. Следовательно, в коде мы должны определить только реальную функциональность. Итак, рассмотрим, что у нас есть на данный момент. Среда Xcode при создании проекта определила для нас несколько классов, и мы, прежде чем вносить в них какие-либо изменения, поближе познакомимся с каждым из них.

Начнем с рассмотрения файла заголовка делегата PresidentsAppDelegate.h, который выглядит следующим образом.

Этот делегат подобен некоторым другим делегатам приложений, уже рассмотренным е этой книге. Главное отличие этого делегата состоит в том, что он содержит выходы (outlet) не на один контроллер, а на несколько. Это позволяет нам использовать данный делегат приложения в качестве центральной точки, из которой мы можем получить доступ ко всем кои троллерам. Рассмотрим файл реализации PresidentsAppDelegate.m (мы удалили из него большинство комментариев и пустые методы).