Создание демо и полной версии приложения на основе одной кодовой базы/проекта

Я разработал одно приложение для Android в одном проекте с Eclipse — оно структурировано (исходя из iPhone), поэтому одна константа определяет, будет ли это демо или полная версия.

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

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

Я вижу три возможных подхода:

1. Хотя я просматривал библиотечные проекты, мне все еще неясно, как это действительно обеспечивает хорошее решение в этом случае.

Например, если у меня есть полная версия со структурой действий:

A1
A2
A3

используя классы полезности U1,U2

Конечно, U1 и U2 могут быть в проекте библиотеки и ссылаться на них из обоих проектов, но действия, strings.xml, графика, макеты должны быть продублированы (или есть другой способ, который я не вижу?) Это не похоже быть хорошим шагом вперед и, к сожалению, не было объяснено в аналогичных вопросах по этой теме, когда был предложен этот подход.

2. Другим способом было бы создание разных имен пакетов на основе разных настроек сборки (аналогично iPhone), однако это кажется невозможным в Eclipse, а не с использованием некоторых внешних сценариев (чего, честно говоря, я предпочитаю избегать, поскольку это кажется довольно подверженным ошибкам), в то время как компиляция должна быть вызвана вне Eclipse

3. Вероятно, самый простой подход (и также в настоящее время с минимальными усилиями) - просто вручную скопировать проект, изменить одну константу, переименовать пакет и компилировать/экспортировать каждый раз, когда я отправляю. Однако это кажется довольно «базовым» и, конечно, не выглядит профессиональным (по сравнению с настройкой/целевым решением сборки iPhone/xCode)

Каким будет наилучший подход (требующий минимального количества изменений и при этом стабильный и простой в использовании)?

Большое спасибо!

РЕДАКТИРОВАТЬ

Для всех, кто попробовал решение Тима - оно работает нормально, однако я столкнулся с проблемой с пользовательскими атрибутами.

Проверьте это: Как решить проблемы с библиотеками Android. настраиваемые атрибуты и переназначение имен пакетов во время сборки? это решит проблему с библиотеками


build android android-library conditional-compilation
person user387184    schedule 18.10.2012    source источник

Ответы (3)


arrow_upward
8
arrow_downward

Я делаю это в настоящее время в затмении, и это не сложно.

  1. Преобразуйте существующий исходный код в библиотечный проект.

  2. Создайте два новых проекта, бесплатный и платный.

  3. Включите проект библиотеки в бесплатные и платные проекты.

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

Я использую один и тот же код для обоих проектов и различаю их, говоря:

if(getApplicationContext().getPackageName().equals("full version package name")) {
    //do full stuff
} else {
    //do free stuff
}

Некоторые ошибки, с которыми я столкнулся, особенно если вы уже выпустили свое приложение на рынок:

  • Если вы измените полное имя/путь какого-либо действия, оно исчезнет с рабочего стола. Поэтому, если ваша библиотека имеет другое имя пакета, чем существующая версия, вы потеряете все значки на рабочем столе. Их может заменить пользователь, но это не идеально.
  • Аналогично виджетам приложений: если вы измените имя получателя, они исчезнут при обновлении.
  • Вы не можете ни при каких обстоятельствах изменять имя пакета выпущенного приложения.

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

В моем случае я выпустил только бесплатную версию, прежде чем разделить их, и я смог назвать библиотеку то же имя пакета, что и бесплатная версия. Я скептически относился к тому, что вам будет разрешено включать библиотеку с тем же именем пакета, что и у пакета-оболочки, но, по-видимому, это возможно (у меня работает нормально).

Итак, в моем случае у меня есть три проекта:

  • Базовая библиотека: имя пакета: com.myname.myapp
  • Бесплатная версия: имя пакета: com.myname.myapp
  • Версия Pro: имя пакета: com.myname.myapp.Pro

Манифесты бесплатной и полной версии добавляют действия с именами com.myname.myapp.ActivityA или com.myname.myapp.ActivityB, которые существуют только в проекте библиотеки.

person Tim    schedule 18.10.2012
comment
большое спасибо за дополнительное разъяснение - я попробую это в ближайшие пару дней (пока я еще не выпустил ни одного из двух в GooglePlay - к счастью, как я понял из вашего комментария :-) - person user387184; 19.10.2012
comment
Мне это нравится. Надо будет взять на заметку в следующий раз. - person DeeV; 19.10.2012
comment
Я попробовал этот подход. Основная проблема здесь в том, что вам нужно скопировать код, и в итоге у вас будет три проекта! Лучший способ - использовать ароматизаторы. Это отличный учебник, который мне помог: youtube.com/watch?v=7JDEK4wkN5I - person electronix384128; 16.04.2014

arrow_upward
2
arrow_downward

Я вижу, что самым простым подходом было бы иметь три проекта:

  1. демо
  2. полный
  3. библиотека

Демонстрационный и полный проекты будут иметь свое собственное уникальное имя пакета, определенное в соответствующем файле манифеста. Их действия — это просто порты, которые отправляют информацию в пакете на основное действие в библиотечном проекте. Activity в библиотечном проекте будет считывать переданный Bundle для необходимых параметров, определяющих, был ли он запущен демонстрационным Activity или полным Activity. Тогда это будет происходить соответственно.

Итак, логика такая:

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

OR

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

person DeeV    schedule 18.10.2012
comment
Хотя это возможно, нет необходимости в том, чтобы действие-оболочка передавало пакеты в библиотеку. Вы можете создавать экземпляры библиотечных действий непосредственно в манифестах пакета выпуска. Смотрите мой ответ для более подробной информации. - person Tim; 19.10.2012

arrow_upward
1
arrow_downward

Это очень просто с помощью build.gradle в Android Studio. Прочтите о о вкусах продукта. Это очень полезная функция. Просто добавьте следующие строки в build.gradle:

productFlavors {
    lite {
        packageName = 'com.project.test.app'
        versionCode 1
        versionName '1.0.0'
    }
    pro {
        packageName = 'com.project.testpro.app'
        versionCode 1
        versionName '1.0.0'
    }
}

В этом примере я добавляю два варианта продукта: первый для облегченной версии и второй для полной версии. Каждая версия имеет свой versionCode и versionName (для публикации в Google Play).

В коде просто проверьте BuildConfig.FLAVOR:

if (BuildConfig.FLAVOR == "lite") {
   // add some ads or restrict functionallity

}

Для запуска и тестирования на устройстве используйте вкладку «Варианты сборки» в Android Studio для переключения между версиями: введите описание изображения здесь

person Denis    schedule 01.12.2014