Есть ли "лучшая практика" для организации в Xcode 4?
Я иду из мира java, где файлы/классы должны быть хорошо структурированы в пакетах/папках в моем понимании.
Какова наилучшая практика в Xcode4? Я пока не мог найти руководство Apple. Если кто-то может подтолкнуть меня к правильному документу, я буду счастлив.
Если нет документа: что лучше делать? Мне немного странно иметь все классы в одной папке проекта - либо внутри Xcode-представления, либо файловой структуры (как ни странно filestructure не похоже на визуальную структуру в Xcode). Разумеется, проект будет посвящен управлению версиями (на GitHub).
Большое спасибо заранее!
Ответы
Ответ 1
Прежде всего, мне нравится группировать категории контроллеров пожара и связанных классов. Но не только в группах, созданных в XCode, в реальных папках тоже. Итак, создав группу вместо ее создания в XCode, сначала создайте ее в Finder, затем перетащите эту папку в XCode и сформируйте ее в группу. Теперь, когда вы добавляете новые файлы в эту группу, они также попадают в эту папку на диске.
Некоторые другие случайные мысли:
Именование: поскольку у вас нет пространств имен, вы должны префикс своих классов с двух или трехбуквенным префиксом (Apple рекомендует три). Сделайте это, даже если сначала кажется странным.
Ресурсы. Проекты по умолчанию - это отделить файлы xib от контроллеров представлений. В приложении любого размера я предпочитаю хранить контроллеры представлений и xib файлы, сгруппированные в одном месте. Вы могли бы даже делать изображения таким образом, хотя, как правило, их достаточно, чтобы просто сгруппировать их в одном месте.
Приложения: мне нравится группировать все разные файлы приложения (делегат приложения, info.plist, файл pch, main.m и т.д.) в одной группе приложений в верхней части списка, чтобы сделать эти биты найти.
Ответ 2
Прежде всего, взгляните на структуру проекта по умолчанию. Хотя это не идеально, в Xcode есть некоторые "Группы" по умолчанию. Используйте их как общие рекомендации. (Как вы упомянули, группы не являются файловыми папками, хотя при импорте ресурсов вам предлагается указать группы для папок.)
Пока не существует большого количества официальных соглашений о структурировании файлов, есть некоторые вещи, которые вы можете сделать, как я, чтобы поцарапать этот организационный зуд. Я делаю несколько подпапок в моей директории проектов на моем диске. Вот некоторые из них:
-
Аудио: Аудиофайлы также могут иметь свою собственную группу.
-
Внешние библиотеки: Если я импортирую код других людей, я создам группу под названием "библиотеки", а затем подгруппу для каждого из них.
-
Изображения: Там вы можете сделать подпапки/подгруппы, если хотите. (Один для значков, один для главного меню и т.д.)
-
Управляемые объекты: Когда я использую Core Data в своих проектах, я часто создаю подклассы с помощью инструментов моделирования Xcode. Мне нравится сохранять их в отдельной группе и в отдельной папке.
-
Контроллеры просмотра: В зависимости от проекта я мог бы по-разному группировать мои контроллеры. Например, я могу хранить всех моих "редакторов" и "зрителей" в разных группах.
В конечном счете, группы предназначены для упрощения управления проектами, а папки - для упрощения управления файлами. Это полностью зависит от вас, как это сделать. Как отмечает Билл Браски, во время компиляции ни одна из организаций не имеет никакого значения. (Если вы хотите сходить с ума, взгляните на экран "Build Phases" в Xcode 4. Фаза копирования - это беспорядок всех ваших соответствующих файлов.)
Ответ 3
Я не сталкивался с конкретными делами/не делаю, когда речь заходит о том, как вы организуете свой проект в XCode. Я мог ошибаться, но я считаю, что любые папки и макеты, которые вы создаете сами, в любом случае полностью удалены во время компиляции.
Например, если у вас есть изображение, вложенное в Ресурсы/Изображения/Фон/image.png, вы все равно просто ссылаетесь на имя файла .png, а не на структуру папок.
Я бы сказал, что вы все равно можете организовать свой проект по своему усмотрению. Заимствуйте часть из java и выложите все, что лучше всего работает.
Ответ 4
Это по-вашему. Организатор не отражает фактическую структуру файла. В конце концов исходные файлы просто скомпилируются в двоичный файл, а все ресурсы просто сбрасываются в папку "Ресурсы" в комплекте для вашего приложения. Я просто расширяю настройку по умолчанию - я помещал ресурсы в папку ресурсов, сгруппированные по мере необходимости. В игре у меня могут быть группы для значков, фона, спрайтов, аудио и других. Для приложения с производительностью у меня могут быть только текстуры и значки. Внешние библиотеки и Framework все входят в группу Frameworks (я редко беспокоюсь об их организации, за исключением случаев, когда какая-либо библиотека, такая как Dropbox SDK или GData, уже поставляется в аккуратной группе. Обычно это всего один файл). В группе "Источники" я могу группировать по функциональным представлениям, таким как "Библиотека документов", "Редактирование вида" или "Утилиты" (для программы редактирования документов) или "Главное меню" и "Геймплей" для игры. Для меньшего проекта я могу группировать контроллеры (в случае необходимости разделять на контроллеры представлений и контроллеры модели), модели и представления. Если вы используете Java-проект, нет ничего плохого в сохранении существующей организации; Фактически, по умолчанию, когда вы добавляете в Xcode, он будет создавать новые группы в соответствии с папками на диске.
Все равно выровняется в конечном пакете, и ваша организация не влияет на файловую систему. Используйте все, что необходимо для проекта, не используйте ту же структуру для клона Tetris, как и для... профессионального медицинского приложения или чего-то еще.