Несколько приложений с общей кодовой базой

Так как популярно иметь как бесплатную, так и платную версию на рынке Android того же приложения, я решил сделать то же самое. Первоначально я просто продублировал полную базу кода и адаптировал некоторый код здесь и там (добавленные объявления, встроенные ограничения и т.д.), Поскольку в то время не было возможности выполнять проекты библиотеки, но это оставило меня с двумя проектами, которые ужасно влияют на исправления к ошибкам, поскольку мне нужно сделать это дважды.

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

Могу ли я использовать весь код в общем проекте и иметь простой проект кости, в основном только манифест?
- Если да, должен ли я? это оптимальный путь концептуально? (так что кроме того, что это зависит от моей базы кода)
Как мне обращаться с именами пакетов библиотеки, существуют ли определенные правила?
Есть ли инструменты, которые могут сравнивать код из двух разных проектов и, возможно, объединить их автоматически или автоматически вручную, и какой из них предпочтительнее?

Ответ 1

Да, у вас может быть проект, который в основном представляет собой только манифест, определяющий имя приложения, пространство имен, значок и т.д. со всем фактическим кодом и 99% ресурсов в проекте библиотеки.
/li >
Да, я думаю, вы должны использовать этот подход. Очень распространено использование библиотечных проектов для решения проблемы с Free/Paid app.
У меня не было проблем с именованием, хотя вы должны быть осторожны с любыми ресурсами в отдельных проектах, чтобы избежать использования тех же имен.
Я не знаю о каких-либо инструментах, и если бы это был я, я бы хотел сделать это вручную, чтобы быть уверенным, что я сливаю то, что нужно для слияния и хранения отдельно, что нужно быть отдельным. у вас есть один важный рефакторинг, но как только все дублирование будет удалено, я уверен, что это будет намного проще.

Ответ 2

Если я правильно понимаю вашу проблему, вы хотите создать несколько приложений для Android, которые похожи друг на друга (т.е. имеют один и тот же исходный код), но которые отличаются, в частности (второстепенными) способами, и вы хотите каждое из этих приложений имеет отдельный пакет, чтобы его можно было отдельно загружать и распространять в магазине приложений, таком как Google Play. Библиотека проекта - отличное средство для достижения этих целей.

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

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

Библиотека проектов может быть определена в Eclipse так же, как любой проект Android может быть определен, но она помечена как Библиотека проектов (путем проверки поля "Является библиотекой" в нижней части страницы Android библиотеки Диалоговое окно "Свойства проекта" ) и не может быть скомпилировано и запущено самостоятельно. Вместо этого он предназначен для включения в качестве ссылки в один или несколько других проектов, которые являются реальными приложениями (добавив ссылку на него на странице Android каждого такого диалогового окна "Свойства проекта" ). Эти приложения будут использовать библиотеку проектов и, таким образом, будут делиться своим кодом и возможностями.

Каждое такое приложение для ссылок будет иметь свой файл манифеста (где могут быть объявлены их соответствующие, разные пакеты), а также они могут определять свои собственные классы (включая классы, полученные из классов Activity и/или Application библиотеки проектов), так что эти классы могут быть специализированно полиморфно для каждого приложения, которое использует библиотеку проектов (например, путем переопределения методов или путем предоставления определений для методов, которые определены как абстрактные в классах, связанных с деятельностью в рамках Библиотеки проектов или приложений), хотя вы можете также используйте эти классы библиотеки без изменений (при условии, что они не являются абстрактными), просто ссылаясь на них в файле манифеста (например, в теге активности или приложения) каждого приложения, которое использует библиотеку, так же, как вы ссылаетесь на Activity или Application- производные классы, определенные в самом приложении.

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

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

Что касается именования пакетов, любое старое имя пакета будет работать для проекта библиотеки, но, конечно, имеет смысл использовать тот же префикс для пакета Library Project, который вы используете для своих отдельных (например, бесплатных или платных) приложений которые используют его, с чем-то вроде ".library" в качестве последней части имени, в то время как различные приложения могут иметь такие окончания, как ".myappfree" и ".myapppaid". Естественно, вы хотели бы использовать соглашение об обратном доменном имени для префикса пакета библиотеки для предотвращения конфликтов, так же, как и для имени пакета выпущенного приложения.

В Windows хороший инструмент с открытым исходным кодом для сравнения баз кода - это WinMerge:

http://winmerge.org/

Если бы я был на вашем месте, я бы использовал этот инструмент только для ручного определения различий и не пытался использовать его для автоматизации реорганизации вашего кода в проект библиотеки. Это лучше всего сделать под вашим собственным (ручным) контролем.

Наконец, в качестве альтернативы вы можете использовать одно бесплатное приложение, которое по умолчанию имеет ваши бесплатные возможности приложения, с возможностью обновления до полных возможностей приложения (поставляемых в одном и том же APK) а не отдельные бесплатные и платные приложения. За последние несколько месяцев платежи с помощью приложений значительно улучшились (с выпуском версии 3 IAB), и хотя все еще есть некоторые сбои, они стали более практичной альтернативой свободной/полной дихотомии, чем в первый.