Есть ли «лучшая практика» для организации в Xcode 4? - PullRequest
15 голосов
/ 11 августа 2011

Я из мира java, где файлы / классы должны быть хорошо структурированы в пакетах / папках в моем понимании.

Какова лучшая практика в Xcode4?Я не мог найти руководство Apple для этого еще.Если кто-нибудь сможет подтолкнуть меня к нужному документу, я буду счастлив.

Если нет документа: что лучше сделать?Я нахожу немного странным иметь все классы в одной папке проекта - либо внутри Xcode-view, либо в файловой структуре (странно, что файловая структура, похоже, не равна визуальной структуре в Xcode).Конечно, проект будет на контроле версий (на GitHub).

Заранее большое спасибо!

Ответы [ 4 ]

9 голосов
/ 11 августа 2011

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

Некоторые другие случайные мысли:

Именование: поскольку у вас нет пространств имен, вы должны поставить префиксклассы с двух или трехбуквенным префиксом (Apple рекомендует три).Делайте это, даже если поначалу это кажется странным.

Ресурсы: Проекты по умолчанию предпочитают отделять файлы xib от контроллеров представления.В приложениях любого размера я предпочитаю хранить контроллеры представления и файлы XIB, сгруппированные в одном месте.Вы даже можете сделать изображения таким способом, хотя обычно их достаточно, просто сгруппировать их в одном месте.

Прикладные программы: мне нравится группировать все разные файлы, относящиеся к приложениям (делегат приложения, info.plist, файл pch, main.m и т. д.) в одной группе приложений в верхней части списка, чтобы эти биты было легко найти.

7 голосов
/ 11 августа 2011

Прежде всего, взгляните на структуру проекта по умолчанию.Хотя он и не идеален, в Xcode есть некоторые «Группы» по умолчанию.Используйте их в качестве общего руководства.(Как вы упомянули, группы не являются папками файловой системы, хотя при импорте ресурсов вам предлагается опция создания групп для папок.)

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

  • Аудио: Аудиофайлы также могут иметь свою собственную группу.

  • Внешние библиотеки: Если я импортирую чужой код, я создам группу под названием «библиотеки», а затем подгруппу для каждой.

  • Изображения: Там вы можете создавать подпапки / подгруппы, если хотите.(Один для значков, один для главного меню и т. Д.)

  • Управляемые объекты: Когда я использую базовые данные в своих проектах, я часто генерирую подклассычерез инструменты моделирования XCode.Мне нравится хранить их в отдельной группе и отдельной папке.

  • Контроллеры представления: В зависимости от проекта я могу сгруппировать контроллеры представления по-разному.Например, я мог бы хранить все свои «редакторы» и «средства просмотра» в отдельных группах.

В конечном счете, группы предназначены для упрощения управления проектами, а папки - для упрощения управления файлами.,Это полностью зависит от вас, как это сделать.Как указывает Билл Браски, во время компиляции ни одна из организаций не имеет значения.(Если вы хотите сойти с ума, взгляните на экран «Build Phases» в Xcode 4. Фаза копирования - это путаница всех ваших соответствующих файлов.)

2 голосов
/ 11 августа 2011

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

Например, если у вас есть изображение, вложенное в Resources / Images / Background / image.png, вы все равно просто ссылаетесь на имя файла .png, а не на структуру папки.

Мне бы пришлосьскажем, вы можете организовать свой проект так, как считаете нужным.Одолжите немного из Java и выложите все, что лучше всего работает.

1 голос
/ 11 августа 2011

Это действительно вам по вкусу.Организатор не отражает фактическую файловую структуру.В итоге исходные файлы просто скомпилируются в двоичный файл, а все ресурсы просто сбрасываются в папку «Ресурсы» в комплекте для вашего приложения.Я просто расширяю настройки по умолчанию - я помещаю ресурсы в папку ресурсов, сгруппированных по мере необходимости.В игре у меня могут быть группы для иконок, фонов, спрайтов, аудио и других.Для высокопроизводительного приложения у меня могут быть только текстуры и значки.Внешние библиотеки и Frameworks все входят в группу Frameworks (я редко пытаюсь организовать их, за исключением случаев, когда некоторые библиотеки, такие как Dropbox SDK или GData, уже входят в аккуратную группу. Обычно это всего лишь один файл в любом случае).В группе «Источники» я могу группировать по функциональным представлениям, таким как Библиотека документов, Представление редактирования или Утилиты (для программы редактирования документов) или Главное меню и Геймплей для игры.Для меньшего проекта я мог бы сгруппировать по Контроллерам (разделить на Контроллеры Представления и Контроллеры моделей при необходимости), Модели и Представления.Если вы пришли из проекта Java, нет ничего плохого в сохранении существующей организации;фактически, по умолчанию, когда вы добавляете в Xcode, он создает новые группы в соответствии с папками на диске.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...