У меня есть приложение MacOS appkit с множеством разных NS Windows (сотен), и каждый из них создан из раскадровок.
Многие из этих NS Windows имеют контейнерные представления со сложным встроенным представлением / view контроллера иерархий.
Во время инициализации необходимо знать объект модели, связанный с любым данным NSWindow, чтобы его подпредставления и элементы управления могли быть должным образом инициализированы. Поскольку любой NSController может знать свой NSView, а любой NSView может знать его NSWindow, было бы неплохо, чтобы эта информация сохранялась с NSWindow.
Было бы замечательно установить «presentObject» для NSWindow, но в отличие от NSViewController, у него на самом деле его нет.
Это единственное реальное решение для создания простого пользовательского класса (производного от небольшого базового класса) для каждого объекта раскадровки NSWindow, поэтому NSViews & NSViewControllers вниз иерархия представления может получить данные моей модели (указатель)?
УТОЧНЕНИЕ: очень немногие из моих объектов NSWindow в наших сотнях раскадровок имеют собственные классы или код, производный от NSWindow. Поэтому, хотя Категория определенно полезна для добавления API к классам для ДОСТУПА к данным модели, связанным с NSWindow, это не полезно при создании свойства или переменной экземпляра и инициализации его во всех этих раскадровках NSWindow.
В конечном итоге я представляю простое, но отвратительно плохое решение, никому не нужно копировать:
Наше приложение не использует NSDocument, который предоставил бы средство для ассоциирования NSWindow объекты с архитектурой документа / модели. Поэтому наша цель состояла в том, чтобы позволить каждому NSController и NSView получить доступ к соответствующему объекту модели отдельного документа, необходимому для инициализации элементов управления представлением.
Меня предупредили гуру инженеров Apple, что я не могу зависеть от порядок, в котором представления и подпредставления создаются и инициализируются. Это делает передачу данных в сложные встроенные подпредставления раскадровки сложными и подверженными ошибкам.
Но - при всем пользовательском интерфейсе в главном потоке невозможно для одного приложения в MacOS создавать, инициализировать и отображать одна раскадровка И есть другая инициализация раскадровки и отображение прерывания этого процесса (по крайней мере, не наши раскадровки приложения, вызываемые пользователем). Таким образом, простое решение состоит в том, чтобы ...
... иметь временно установленный глобальный уровень приложения с указателем желаемой модели документа . Это и счетчик на основе стека, чтобы гарантировать, что вышеупомянутые предположения никогда не нарушаются. Ужасный дизайн . Эффективное решение .
Никто не должен напоминать мне, ПОЧЕМУ это не хорошо. Но если есть лучшее решение, оно избежало моих испытаний. Я обнаружил, что даже viewDidLoad и viewWillAppear нельзя доверять, чтобы указатель solid возвращался к своему NSWindow ...