Каковы лучшие практики и рекомендации организации решения XCode?

Question

Существуют ли передовые методы организации своего решения в xcode

Это моё на данный момент из корня:

• Папка для каждого стороннего фреймворка, например KissXML
• Папка для моих юнит-тестов
• Папка для фреймворков, продуктов и ресурсов
• Папка для MyApp, в которой есть подпапки для модели, вида, контроллера, базы данных, вспомогательных файлов и домена.

Answer 1

Шахта это:

Main application
    Model
    Singletons
    Helper+managers
    Controllers    // I keep nibs with their respective class files
    View
    Resources
        images
        plists
        //  ... groups from other types of resources if needed
    Supporting files
Unit tests
Frameworks

Для многократно используемого кода на iOS я использую статические библиотеки и добавляю их как отдельные проекты в рабочее пространство Xcode. Даже для стороннего кода, если нет статической целевой библиотеки, я создаю ее. Таким образом, я обращаюсь со сторонним кодом так же, как и со своим собственным библиотечным кодом. Кроме того, мне не нужно беспокоиться о версии стороннего кода.

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

Answer 2

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

1. Папка для ядра приложения или модели.Сюда входят подпапки для любых сторонних используемых библиотек и папки для специализированных классов моделей.Например, там будет папка для обработки веб-службы.

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

3. Папка для второго основного модуля и т. д.

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

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

Конечно, у этой схемы были бы недостатки, но эта схема хорошо подходит нам уже много лет:)