andrey7mel Oct 26 2015 at 19:21

Конвейерное производство Android приложений

6 min

20K

Rambler&Co corporate blogDevelopment of mobile applications*Development for Android*

+12

Comments 18

ookami_kb Oct 26 2015 at 19:51

Была (да и есть) похожая задача по разработке и поддержке ~15 приложений, отличающихся содержанием + немного оформлением. В итоге всё-таки пришли к flavors. Если все версии всё равно в одном проекте — то смысла особого в выделении библиотеки как-то не вижу. Просто весь общий код выносится в main, а конкретные приложения разносятся по flavors.

На Publishing API давно засматриваюсь, но всё надеюсь, что запилят поддержку в Android Studio — было бы логично и удобно.

agent10 Oct 26 2015 at 22:27

Скажите, а не усложняется ли навигация по проекту, когда весь общий код в main?
В нашем проекте ~7 приложений, исторически весь общий код как раз вынесен в отдельный library project, тогда как основной flavor main «пустует».
Пока переносить я не решаюсь, сейчас визуально работать проще(как мне кажется)…

ookami_kb Oct 26 2015 at 22:39

общий код как раз вынесен в отдельный library project

Т.е. прям лежит в отдельном проекте, там компилируется, и подключается к приложениям через jar/aar? Я просто так одну библиотеку свою тяну, которая в нескольких проектах используется, и каждый раз при изменении чего-нибудь в ней приходится кучу шагов предпринимать… так что мне кажется это сильно неудобно.

А особых неудобств main не доставляет — лежит себе спокойно; по сути, в отдельной папке всё инкапсулировано; зато, если надо что-то подправить, всегда под рукой.

agent10 Oct 26 2015 at 22:49

Да, прямо так и лежит. Но подключается зависимостями через gradle. Но у нас, 90% работы именно с общим кодом. А как думаете ускорится ли сборка при переносе в main?

ookami_kb Oct 26 2015 at 23:01

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

agent10 Oct 28 2015 at 21:02

Попробовал ради интереса перенести, прирост всё же есть, но не очень значительный: на моей машине быстрее стало строиться примерно на 9%. До переноса среднее время было 112 секунд, после стало 102 секунды.

kolipass Oct 27 2015 at 09:14

Поддерживаю мнение о правильности реализации через gradle. Само собой договариваемся, что ядро лежит в maven репозитории, пусть даже и в приватном (хотя бы локальном).
Как факт — можно вообще отказаться от использования flavor и получить полностью независимые от соседей проекты. А ведь рано или поздно кто-то из заказчиков захочет себе много штук, которые будут нужны только ему: какая-нибудь интеграция кинофестиваля в календарь или реалтайм пушилка сообщений о лауреатах Оскара(с предметной облостью не знаком, думаю, имеются живые примеры). Или вообще захочет забрать исходники и свалить к другим. В таком случае вы отдадите только кастом код+ ссылку на зависимость из gradle репозитория.

rogrom Oct 26 2015 at 20:30

Было бы интересно увидеть именно деплой-скрипт, как вариант — в виде плагина для Gradle

anonymouz Oct 26 2015 at 20:45

Вот эта штука работает: github.com/Triple-T/gradle-play-publisher

VitaZheltyakov Oct 26 2015 at 23:40

Хотите быстро, легко и универсально, то используйте связку HTML5 + СocoonJS (или Cordova)

-5

BIanF Oct 28 2015 at 06:27

Вы статью-то читали?

VitaZheltyakov Oct 28 2015 at 11:02

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

agent10 Oct 28 2015 at 12:38

Статья об архитектурных подходах кастомизации/брендирования нативно написанных приложений с кучей кода и кучей заказчиков… Как технологии, которые вы перечислили связаны с этим?

VitaZheltyakov Oct 28 2015 at 12:44

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

Bringoff Jan 29 2016 at 11:59

Эти технологии позволяют создавать нативные приложения на основе web-приложений

Кажется, вы не в курсе, что такое нативные приложения.

akimovpro Oct 27 2015 at 11:11

Недавно Fastlane запилили под Android (пока бета) — github.com/fastlane/fastlane/blob/master/docs/Android.md
Под iOS отличный продукт для быстрого деплоя.

KamiSempai Oct 27 2015 at 19:19

Зря вы класс назвали как «FragmentManager» может получиться путаница с классом «android.app.FragmentManager».

BIanF Oct 28 2015 at 06:29

Читаю статьи такие и всегда думаю какие же крутые бывают спецы =)
У меня тоже схожая задача, но благо приложения (>100) отличаются только ресурсами. Есть приложение Template, которое редактируется через IDE, как и любое другое + Python скрипт, который подменяет ресурсы, файлы подписи и билдит.

-1