Управление несколькими версиями приложения iOS
допустим, у меня есть приложение iOS для, скажем, футбольных новостей, теперь я хочу создать другую версию для новостей баскетбола, которая будет основана в основном на футбольном приложении, но со свободой создавать другое поведение в некоторых аспектах каждого приложения + добавление дополнительных приложений в будущем для других новостных тем.
другое условие заключается в том, что они будут иметь отдельную модель CoreData, активы, значок и т. д.
Как я понимаю, у меня мало опции:
- Управление приложениями отдельно, поместите их в тот же каталог и укажите общие файлы в первом (футбольное приложение).
- создайте другую цель для каждого приложения в том же проекте
- создать рабочее пространство с одним проектом, который будет содержать общий код и проект для каждого проекта.
какие плюсы / минусы для каждого варианта и каковы лучшие практики в этой ситуации ?
просто уточните - приложения, которые я упоминаю, являются примером, приложение не для новостей,и это должно быть другое приложение для каждой концепции.
спасибо
6 ответов
Я работаю в корпоративной среде, и у нас есть мобильное приложение, что продукт компании в которой я работаю. Мы продаем лицензии на это программное обеспечение нашим клиентам, которые всегда являются огромными компаниями. Наше приложение не проходит через App Store.
У каждого из наших клиентов есть какая-то настройка в приложении, либо просто изменив свои логотипы, либо даже добавив некоторые конкретные функции для одного из них. Что я имею в виду: мы имеем дело с ситуацией очень близко к то, что вы описываете, и вот мои два цента.
заранее: извините, если я иногда слишком честен, я не хочу никого обидеть.
1. Управление приложения в отдельности, разместить их в одном каталоге и указать на общие файлы в первом (футбол).
хорошо... Это странное решение, но оно может сработать. Это может быть трудно поддерживать локально и еще сложнее при использовании SVN / Git (особенно при работе в команде).
У меня были некоторые проблемы, связанные с символическими ссылками раньше, но я не уверен, что это то, что вы имеете в виду в этой опции. Если вы объясните немного лучше, я могу отредактировать это и попытаться дать вам лучшее мнение.
2. Создайте другую цель для каждого приложения в том же проекте
Это лучшее начало, на мой взгляд.
мы используем этот подход в основном для обработки различных возможных backend сервера. Например, один из наших цели используют наш сервер разработки, в то время как другая цель использует производственный сервер. Это помогает нам гарантировать, что мы можем использовать целевое приложение без риска серьезных затрат для нашей команды (например, из-за ошибочно размещенного заказа).
в вашем случае вы можете, например, настроить макросы препроцессора для целей, чтобы включить / отключить некоторую целевую функцию, вызываемую кодом. Вы также можете использовать разные раскадровки для каждого цель.
недостатком этой опции является то, что код будет беспорядочным, потому что каждый фрагмент кода будет находиться в одном проекте. Это основная причина, по которой я бы пошел с вариантом № 3.
3. Создать рабочее пространство с одним проектом, который будет содержать общий код и проект для каждого проекта.
опять же, я бы пошел на это. Честно говоря, мы пока не используем это в нашей компании, но это связано с внутренними причинами. Я пытаюсь сделать это для наших проекты как можно скорее.
Я бы не назвал его простым в настройке, но если все сделано правильно, это может помочь вам сэкономить время из-за причин обслуживания. Вы сможете повторно использовать любой код, который можно повторно использовать, и по-прежнему сможете сохранять свои целевые изображения, классы и представления в своем собственном "контейнере"(проекте).
таким образом, вы получите проект по умолчанию (само приложение), несколько целей для него и "фреймворк", чтобы сохранить код для каждой из целей. Другими словами, вы сможете поделиться код между несколькими целями/приложений, и в то же время вы сможете отделить то, что принадлежит каждому из них. Нет грязный проект:)
Я не уверен, как CoreData компилируется Xcode, так как мы его не используем. Но проверьте ответ, который я только что сделал для еще вопрос. Это не быстро, но это не должно иметь большого значения, поскольку почти весь ответ заключается в настройке рабочей области для достижения этого решения. К сожалению, я думаю, что он слишком большой, поэтому я связываю ответ, а не вставляю его здесь.
Если вам нужна помощь при этом, дайте мне знать, и я сделаю все возможное, чтобы помочь вам.
Это может быть излишним для вас, но это решение масштабируемо. Нам пришлось создать ~15 приложений из одной кодовой базы
проблема, которую мы должны были решить, была брендингом. Дизайн приложения и поток были в основном одинаковыми, наряду со структурой полученных нами данных. Большая часть тяжелой работы была сделана нашим сервером CI.
у нас было основное приложение со всем пользовательским интерфейсом и некоторой общей бизнес-логикой. это было известно как White-app.
у нас тогда был конкретный проект (фреймворки тогда не существовали) для каждой из разных конечных точек и моделей данных и картографов в моделях представления Белого приложения. Эти приложения были частными стручками и управлялись стручками какао.
наш CI был настроен таким образом, что он будет компилировать все "фирменные" приложения, копируя, компилируя, подписывая все различные plist, активы, строковые файлы в каждое приложение Вместе с каждой из конкретных моделей данных для каждого приложения. Поэтому, когда была запущена сквозная сборка, она будет создавать все различные фирменные приложения.
преимущество этого - целевой макет в Xcode не загроможден, у нас была цель выпуска, тестирования и разработки, которая применялась к каждому построенному приложению. Это означало, что наш проект был кратким без риска случайного редактирования настроек сборки фирменных приложений.
Это решение также предоставит вам .xcworkspace (в основном используется какао-стручками), который содержит ссылку на другую модель
Это решение, потому что это работа по настройке i.e при построении в Xcode мы создали специальную схему, которая установила pod и скопировала все правильные активы (как CI)
лучше создать фреймворк, который будет содержать наиболее общий код, необходимый вам во всех 3 вариантах. Кроме того, первый вариант плох в любом случае. Для лучшего контроля лучше иметь 2 или 3 вариант. Рабочее пространство более предпочтительно, imho, так как это не повредит другим подпроектам, если вы, например, решите использовать cocoapods. Рабочая область также позволяет иметь различный набор локализаций в каждом проекте. Кроме того, будут отображаться только цели, связанные с конкретным проектом в списке целей, который лучше, чем куча целей в одной куче (если у вас есть, например, расширение доли во всех продуктах - будет неприятно найти тот, который вам нужен). Что вы выберете зависит от ваших потребностей, но и второй и третий варианты достаточно хороши.
Это вопрос, о котором многие разработчики думали много раз, и они придумали различные решения, специфичные для их потребностей. Вот мои мысли по этому поводу.
положить общие части, которые вы могли бы видеть как ядро, во что-то отдельное-это хорошо. Помимо поддержки повторного использования, он часто улучшает качество кода за счет четкого разделения и чистых интерфейсов. По моему опыту, это также облегчает тестирование. Как вы упаковываете это определяется тем, что ты положил туда. Статическая библиотека-довольно хорошее начало для основной бизнес-логики, но ей не хватает поддержки Swift, и включать ресурсы больно. Фреймворки великолепны, но поднимают планку на минимальную цель разработки iOS. Конечно, если вы просто используете очень мало файлов, просто добавление папки в ваши проекты приложений может работать также - сохранение структуры проекта в актуальном состоянии может быть автоматизировано (это делает Dropbox/djinni), но это нетривиальный подход.
там фактические продукты, котор нужно построить, которые должны включить модуль сердечника, и индивидуальные части. Это может быть проект с несколькими целями, или рабочее пространство с несколькими проектами, или сочетание обоих. В данном контексте я принимаю решение на основе того, насколько близки приложения. Если это просто небольшие изменения от других, как спортивной команды или настройки некоторые функции, как в свете и про это будут различные цели в одном проекте. С другой стороны, я бы использовал другое проекты (возможно, организованные в рамках общей рабочей области), если приложения явно отличаются, такие как клиент Facebook и клиент Twitter, приложение для настольной игры для офлайн-игры и приложение для онлайн-игр и т. д.конечно, есть еще много вещей, чтобы рассмотреть. Например, если вы создаете приложение для клиентов и отправляете источники, возможно, потребуются отдельные проекты .
Я думаю, что лучший способ сделать что-то, что охватывает все 3.
Сначала я бы создал настраиваемую структуру, которая разделяет со всеми целями все, что у них есть общего, от пользовательского интерфейса (элементы, такие как пользовательские оповещения и т. д.) До бизнес-логики.
Затем я создам различные пакеты или папки для каждой цели, проверяя цель членства (таким образом, вы гарантируете только импорт точных ресурсов), затем с помощью макроса препроцессора вы можете создать построитель путей специфично для правого пакета или каталога, в котором находятся ваши ресурсы.
За эти годы я собрал несколько интересных ссылок о лучшей практике.
Вот они:
используйте каталог активов с несколькими целями
используйте несколько тегов XCode 6
Xcode группы vs папки
создание библиотек с ресурсами
создать lite и pro версию приложения
Я знаю, что в SWIFT они внесли некоторые изменения в макросы препроцессора, поэтому некоторые статьи все еще действительны, но немного устарели.
все мы сталкиваемся с такой ситуацией. Но вот то, что я делаю, и, возможно, вы можете выбрать что-то, что может помочь вам. (Надеюсь).
- есть проект, который содержит основные характеристики
- имейте модульные проекты которые могут быть использованы другими вариантами продукта
- управление проектом под контролем версий или git flow, который поможет сохранить основной источник / проект под главной веткой, доступной через ветви / особенности
- при необходимости создайте новую ветку / функцию для варианта проекта или просто включите / отключите или используйте модули проекта, необходимые для этого варианта (все, что наиболее подходит для текущей настройки).
- если приложение имеет веб-службу, к которой он подключается, обеспечить этап лицензирования, где мобильное приложение будет делать это первый запрос на общий (для всех вариантов или даже всех мобильных приложений) URL веб-службы. Эта веб-служба интерпретирует запрос и отвечает данным информация о настройках приложения (например, веб-сервис для подключения к данному номеру лицензии, модули для включения, логотип клиента и т. д.).
- созданные основные проекты и модули могут быть преобразованы в фреймворки, библиотеки или даже пакеты для ресурсов и активов в зависимости от уровня или частоты изменений этих элементов. Если эти элементы постоянно меняются или обновляются другими, не сжимайте их; создайте рабочую область с целями, которые связывают весь проект / модуль к текущему варианту проекта, чтобы изменения в этих модулях отражались немедленно (с учетом контроля версий, конечно).