Архитектура приложения какао в Mac OS X

Я возвращаюсь к разработке Cocoa на Mac после долгой работы с iPhone. Мой предыдущий опыт работы с Cocoa на Mac был просто изящными маленькими инструментами. Я хочу построить что-нибудь серьезное.

Глядя на современное приложение Какао, такое как iPhoto (или Mail, или Things, или ....), многие приложения используют подход «единого окна», основанный на списке источников. Я пытаюсь осмыслить это как можно лучше, потому что, похоже, это дает хороший опыт. Однако у меня небольшая проблема. Вот как, я думаю, это должно выглядеть, но мне интересно, как это делают другие, и что на самом деле лучше всего:

  • Отправной точкой приложения является объект AppDelegate, который после запуска создает Window [Controller?] Из пера вместе с настройкой его данных (например, из CoreData).

  • WindowController загружает окно, в котором, по сути, есть только NSSplitView.

  • В левой части splitview есть NSTableView или NSOutlineView, для которого задан стиль SourceList.

  • На правой стороне находится основное содержимое приложения, в зависимости от того, какой элемент представления таблицы выбран.

Я бы предположил, что где-то (где?) Есть NSViewControllers, управляющие каждым из разных представлений, которые будут отображаться с правой стороны (подумайте, как в iPhoto есть все фотографии, события, лица, места и т. Д., И я предполагаю, что все они могут отображаться в разных перьях ... это правильно?).

Эти контроллеры представления, вероятно, привязаны к исходному списку слева ... как это работает (может быть, исходный список поддерживается NSArrayController из NSViewControllers?).

В любом случае, это мои мысли, я совершенно не в себе или ...? Я поискал в Интернете, нашел это сообщение здесь, и я просмотрел некоторый исходный код Apple, но я не могу осмыслить это. Любое руководство приветствуется.


person jbrennan    schedule 03.09.2009    source источник


Ответы (2)


Разделение представлений на отдельные перья в основном хорошо, если вы собираетесь поменять одни представления на другие, так как вы можете загружать их лениво. И да, в современном приложении вы бы использовали NSViewController или, возможно, KTViewController из KTUIKit (см. сообщения она написала в соавторстве о NSViewController)

Однако не стоит сразу бросаться в объятия списка источников. Однооконный интерфейс может быть хорош для простых приложений, но он может быстро стать громоздким, когда у вас много вещей, так как они могут быть лучше обслужены, разбив их на отдельные окна; iTunes и Xcode предоставляют множество примеров этого (особенно последний, поскольку вы можете переключать его между SWI и MWI).

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

person Peter Hosey    schedule 03.09.2009
comment
Я, конечно, много думал об этом и думаю, что это хорошо работает в моей ситуации. Я думаю, что каждый отдельный взгляд будет достаточно отличаться, чтобы оправдать свое собственное перо, но опять же, я не уверен. При работе с iPhone я редко использовал InterfaceBuilder, однако, учитывая, что привязки так хорошо интегрированы с ним, я думаю, что пора мне начать использовать его больше. Я также читал статьи Кэти, но это еще один шаг в другом направлении, поэтому я не понимаю, как все это должно работать. - person jbrennan; 03.09.2009
comment
Настоящий вопрос не в том, насколько разные представления, а в том, для чего вы их используете - какие объекты модели вы будете в них помещать. Если два представления показывают разные типы вещей, это должны быть разные представления, каждое со своим пером. - person Peter Hosey; 03.09.2009
comment
Да, это были бы разные перья, потому что они показывают разные типы вещей. Как будет работать переключение перьев? Когда я выбираю другую строку в моем списке источников, как это вызывает загрузку нового пера? (Кроме того, следует ли загрузить новый ViewController или просто поменять представление с правой стороны?) - person jbrennan; 04.09.2009
comment
Я полагаю, что у вас будет selectedRowIndexes списка источников, привязанный к свойству владельца окна, который позаботится о загрузке соответствующего контроллера представления для источника по вновь выбранному индексу. Точнее, я не знаю, потому что я когда-либо делал только многооконные интерфейсы. - person Peter Hosey; 05.09.2009

Один из простых способов понять, как разделяются перья, - это просто зайти в каталог iPhoto и начать открывать перья.

Если вы хотите немного подробнее изучить структуру классов, вы можете попробовать просмотреть ее с помощью F-Script

person cobbal    schedule 03.09.2009
comment
Я просматривал некоторые из их перьев раньше, но многие из них - это старые приложения, написанные до таких хороших вещей, как NSViewController, поэтому мне интересно, концептуально, как лучше всего их создать с учетом сегодняшних технологий. - person jbrennan; 03.09.2009
comment
@cobbal Что вы имеете в виду, когда начинаете открывать перья? Когда я просматриваю содержимое пакета приложения и буквально пытаюсь открыть его из Finder, это приводит к ошибке или мало что показывает. Он говорит, что скомпилированные перья не могут быть открыты, когда я использую старый (3.2) Interface Builder, или, в качестве альтернативы, просто показываю огромный значок перья в Xcode 4. - person febeling; 27.02.2012
comment
@febeling вполне возможно, что эта информация уже устарела, но для меня Xcode (4.2) может открывать перья для iPhoto ('09). - person cobbal; 27.02.2012
comment
@cobbal, еще немного покопавшись в этом, кое-что обнаружил. Поскольку перья Snow Leopard скомпилированы. Раньше это были каталоги пакетов, теперь это бинарные списки. Я смог открыть пару старых перьев в моей системе, как вы это описываете. На этой странице описан несерьезный / интересный прием, позволяющий обойти это ограничение для скомпилированных перьев: macstories.net/tutorials/how-to-edit-nib-files-in-snow-leopard Некомпилированные, открываемые и редактируемые перья обычно содержат три файла: keyedobjects.nib, classes.nib и info.nib. Спасибо за указатель в этом направлении! - person febeling; 27.02.2012