Какой хороший способ разделить вкладку UITableViewController на несколько файлов?

Question

Я реализовал вкладку UITableViewController. Вверху есть несколько вкладок, которые перезагружают содержимое таблицы. На основании выбранной вкладки пользователю отображаются разные ячейки. Все это работает хорошо, но в итоге я получаю исходный файл, который содержит 3 различные реализации, и становится немного громоздким и запутанным, даже используя прагмы для пометки разделов исходного кода.

Я думал о создании селекторов во время выполнения из строк на основе выбранной вкладки, затем разбив файл .m на несколько, поместив туда переименованные методы, но затем есть принудительный @end и конец файла и компилятор сообщает вам, что отсутствуют методы для реализации.

Действительно, похоже, цель-c не была предназначена для разделения источника по нескольким файлам. Есть ли шаблон дизайна, который может быть использован для этого? Каким-то образом мне удалось эмулировать все это, используя #include <otherfile.m> до @end основного класса, но это не выглядит красиво. Кроме того, XCode запутывается до чертиков, если я пытаюсь включить этот файл в проект, поскольку он пытается скомпилировать его отдельно (по крайней мере, я могу включить файлы в проект и отключить их включение в целевой объект).

Answer 1

В итоге я прибег к основному препроцессору, что означает включает в себя и некоторые хитрости. Вот что я сделал:

1. Учитывая контроллер табличного представления filename.m, создайте один файл filename_functionality.m для каждой вкладки / группы связанных функций и поместите туда методы. Обратите внимание, что в этом файле нет @implementation, @end, #include и т. Д., Только методы.
2. В вашем проекте XCode добавьте новые файлы, но будьте осторожны, чтобы не пометил их как необходимые для любых целей сборки. Если вы забыли, выберите файлы позже и снимите флажок, который включает их в вашу цель. Это сделано для того, чтобы Xcode не пытался скомпилировать только эти файлы rouge .
3. В конце вашего основного filename.m и непосредственно перед вашим маркером @end добавьте необходимый #include "filename_functionality.m", который эффективно говорит препроцессору обрабатывать все файлы как один.
4. Для случаев, когда ваш основной файл вызывает методы ваших подчиненных файлов, добавьте в начало вашего main файла анонимный интерфейс и объявите там прототипы методов, которые вы переместили в другие файлы.

На данный момент это работает! Тем не менее, XCode все еще действительно раздражает, несмотря на то, что он может открывать подчиненные файлы исходного кода , он не анализирует их должным образом, поэтому вы не можете использовать панель быстрой навигации для перехода между методами, например , Опять же, чтобы решить эту хитрость препроцессора:

1. В начале каждого подчиненного файла добавьте (чёрт, форматирование вики нарушено):

   #ifndef _INCLUDE_FILES

   @implementation BIEntity_view_controller

   #endif

2. В конце вашего подчиненного файла повторите с ifndef, включая @end.

3. В конце вашего основного файла и перед включением определите _INCLUDE_FILES.

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

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

Это не большая проблема, если вы не пишете плохой код (хе-хе) или все равно используете внешний текстовый редактор, но это серьезно повредит, если вы привыкли к клавишам quick fix для перехода с одна строка ошибки к другой.

С помощью этого трюка я разбил файл из 1151 строки на четыре размера по 558, 342, 55 и 145 строк каждый. Теперь функциональность лучше связана, и код все еще может работать как часть того же класса, поэтому мне не нужно писать методы доступа, как это было бы в случае использования языковой конструкции, такой как классы или интерфейсы.