Разработка структуры приложения, которая позволит каждой реализации настраивать части пользовательского интерфейса.

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

Мой текущий подход к фреймворку заключался в разработке Координационного контроллера, который отвечает за все события презентации и увольнения в приложении. Контроллер координации по умолчанию распределяет все контроллеры представления по умолчанию внутри платформы, которые выполняют свои соответствующие задачи, не обязательно предоставляя настроенный пользовательский интерфейс. Например: один контроллер покажет представление коллекции с ячейками шаблона и ничего особенного. Преимущество этой конструкции заключается в том, что она устраняет связь между контроллерами, а также позволяет клиенту переопределять координатор по умолчанию и возвращать совершенно новый контроллер представления для конкретной задачи.

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

Подход первый

Сделайте так, чтобы фреймворк требовал фабрики представлений, и пусть фабрика представлений будет отвечать за реализацию всех соответствующих представлений. Таким образом, в делегате приложения мы могли бы принудить, чтобы клиент, например, создал CollectionViewCellFactory, а интерфейс определяет все ячейки, которые должен предоставить любой соответствующий класс. Я унаследовал кодовую базу с этим дизайном и отошел от нее, поскольку она была слишком абстрактной и настраиваемой. Он поставляется с тоннами фабрик для каждого аспекта приложения, и это добавило дней на время установки каждого приложения.

Подход второй

Каждый контроллер представления задает перехватчики подклассов или API настройки, которые позволят определять эти пользовательские классы пользовательского интерфейса во время выполнения (аналогично тому, как UISplitViewController позволяет вызывающим абонентам устанавливать контроллеры с помощью свойства viewControllers). Для этого каждый клиент просто подклассирует базовый контроллер координации и в каждой презентации контроллеров; установите соответствующие значения на контроллере, чтобы он достиг желаемого пользовательского интерфейса. Что-то вроде

viewController.registerReusableCellsBlock = ^(UICollectionView *collectionView){
   //perform custom registration
}

viewController.cellDequeueBlock = ^UICollectionViewCell<SomeProtocol> *(UICollectionView *collectionView,NSIndexPath *indexPath){
   //dequeue custom cells
}

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

Подход 3

Возможно, это плохая идея попытаться спроектировать структуру и предвидеть ее использование. Возможно, лучшим вариантом является предоставление подклассов с максимальным контролем, даже если стоимость установки относительно высока. Затем, когда я собрал его для нескольких клиентов, я мог бы заметить возникающие шаблоны и начать оптимизацию по маршруту.

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

TL; DR

Самая сложная часть интерфейса связана с представлением коллекции, вложенным в ячейки представления коллекции. Это позволяет осуществлять горизонтальный пейджинг и вертикальную прокрутку ячеек. Это достигается благодаря наличию одного источника данных, который управляет горизонтальными ячейками и настраивает представление коллекции каждой ячейки с новым источником данных.

Как разработать интерфейс, который позволяет настраивать все эти ячейки?

Это старый, но достойный вопрос, который так и не получил достойного ответа, который, по моему опыту, в ответ на

How would one design an interface that allows all these cells to be customizable?

это не делай этого

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

Если им нужно другое решение, они скажут вам. Если они настаивают на индивидуальной настройке, им нужно другое решение и они просто еще не знают.