Pull to refresh

Comments 18

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

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

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

А особых неудобств main не доставляет — лежит себе спокойно; по сути, в отдельной папке всё инкапсулировано; зато, если надо что-то подправить, всегда под рукой.
Да, прямо так и лежит. Но подключается зависимостями через gradle. Но у нас, 90% работы именно с общим кодом. А как думаете ускорится ли сборка при переносе в main?
Мне кажется, не особо. Не думаю, что накладные расходы на разрешение зависимостей будут как-то сильно влиять. Хотя было бы, пожалуй, познавательно узнать результат сравнения.
Попробовал ради интереса перенести, прирост всё же есть, но не очень значительный: на моей машине быстрее стало строиться примерно на 9%. До переноса среднее время было 112 секунд, после стало 102 секунды.
Поддерживаю мнение о правильности реализации через gradle. Само собой договариваемся, что ядро лежит в maven репозитории, пусть даже и в приватном (хотя бы локальном).
Как факт — можно вообще отказаться от использования flavor и получить полностью независимые от соседей проекты. А ведь рано или поздно кто-то из заказчиков захочет себе много штук, которые будут нужны только ему: какая-нибудь интеграция кинофестиваля в календарь или реалтайм пушилка сообщений о лауреатах Оскара(с предметной облостью не знаком, думаю, имеются живые примеры). Или вообще захочет забрать исходники и свалить к другим. В таком случае вы отдадите только кастом код+ ссылку на зависимость из gradle репозитория.
Было бы интересно увидеть именно деплой-скрипт, как вариант — в виде плагина для Gradle
Хотите быстро, легко и универсально, то используйте связку HTML5 + СocoonJS (или Cordova)
Вы статью-то читали?
Я статью прочел внимательно. А вот люди, поставившие мне минус, явно не знают технологий, которые я перечислил
Статья об архитектурных подходах кастомизации/брендирования нативно написанных приложений с кучей кода и кучей заказчиков… Как технологии, которые вы перечислили связаны с этим?
Эти технологии позволяют создавать нативные приложения на основе web-приложений. Преимущества очевидны: простота и скорость разработки, больший охват платформ.
Эти технологии позволяют создавать нативные приложения на основе web-приложений

Кажется, вы не в курсе, что такое нативные приложения.
Зря вы класс назвали как «FragmentManager» может получиться путаница с классом «android.app.FragmentManager».
Читаю статьи такие и всегда думаю какие же крутые бывают спецы =)
У меня тоже схожая задача, но благо приложения (>100) отличаются только ресурсами. Есть приложение Template, которое редактируется через IDE, как и любое другое + Python скрипт, который подменяет ресурсы, файлы подписи и билдит.
Only those users with full accounts are able to leave comments. Log in, please.