Открыть список
Как стать автором
Обновить

Комментарии 12

Тоже делал когда-то подобное. Вставлю свои 5 копеек:
1) Flavors. Всё хорошо когда flavor один на приложение. А у нас было так, что у некоторых приложений были свои дополнительные "подтипы". Тут начинаются приколы, что кол-во комбинации вырастает значительно.
2) Конфиги. У серверного JSON есть ещё преимущество — сразу feature toggle получается можно использовать.
3) Ничего не рассказали о особых кастомизациях под заказчика? Были ли они у вас? Какой процесс был? Бывало ли так, что один из заказчиков хотел "общую" фичу полностью по-другому?

Спасибо за contribution в тему!


1) Жёстко. А сколько примерно приложений было, до 100? Были проблемы с поддержкой из-за громады комбинаций?
2) +, тоже об этом думал.
3) О, крутой вопрос. В статье был похожий момент в пункте 2.2 в контексте цветов, но там надо было с дизайнером внутри команды договориться. С заказчиком помню случай, когда нужна была оплата апгрейда карты лояльности. Мы исследовали её популярность, оказалось, что это узкая тема, поэтому решили не встраивать в общий проект. Делать как кастом для одного flavor тоже не стали — на мой взгляд, если позволять такое, то будет сложно поддерживать код: придётся чекать, что новые фичи не конфликтуют с "особенными" + править "уникальные" баги. В итоге порешали засчёт бэкенда заказчика, на их стороне сервер получал события от нашей системы и проводил оплату боковым путём :)
А как у вас было с кастомами?

3) В зависимости о задачи это были либо обычные флаги, либо если уже "фабрика фабрик", а конкретные реализации которых были внутри flavor приложения.

То есть, заводили параметр, который был общий у всех приложений, кроме одного? Скажем, единственный заказчик хочет меню в виде шторки вместо боттом бара => будет флаг isMenuBottomBar=false у него, а у остальных true?
Выглядит достойно!

Merci, старались :) Надеюсь, этот опыт пригодится в деле!

Крутая статья спасибо
Спасибо, я польщён!

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


Как устроено, много ли версий приходится проверять? Есть ли регресс и если да, как много времени занимает?

Тестирование — отличная тема. Не затронул, ибо объём и так большой, а фокус статьи в первую очередь на архитектуре.

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

Что знаю: так как фичи стандартизированы, чисто логически достаточно проверить все комбинации параметров. Это можно сделать на нескольких сборках, а можно даже выбрать одну и подстраивать её конфиг. Т.е. все приложения смысла проверять не вижу, разве что ребрендинг UI посмотреть.

Если взять ещё шире, ощутимое количество багов превентируем unit-тестами: покрыли слой бизнес-логики и нетривиальные «чистые» классы из ui.
Автоматизация разработки — это хорошо. Но вот если взглянуть со стороны пользователя — допустим, я посещаю 10 магазинов — значит мне нужно устанавливать 10 однотипных приложений, отличающихся только дизайном интерфейса, с одним и тем же бэкэндом? Я не хочу упрекнуть в чём-то именно вас. Но эта политика «каждому сервису — отдельное приложение» на самом деле уже надоела, т.к. она приводит только к захламлению памяти мобильных устройств. Мы же не используем на ПК отдельный браузер для каждого сайта. Общие библиотеки и ресурсы достаточно иметь в одном экземпляре. Возможно, было бы лучше сделать одно приложение — каталог, агрегатор всех дисконтных карт. И уведомления удобнее получать синхронно из одного источника, чем асинхронно из десятка источников.
Здравая позиция, понимаю! Поделюсь личным мнением, оно никак не связано с продуктом или компанией, где я работал.

Как оптимизатор я душой чувствую «избыточные» мегабайты, но как практик люблю расчёт. Представим, что мы в мире, где в среднем у пользователя 5-10 коробочных приложений. При весе одного 5-10 МБ (Лояка) и среднем объёме памяти смартфонов ~68 ГБ избыток будет ~100 МБ — как по мне, это незначительно. Хорошо бы видеть проценты объёма по пользователям, но такого не нашёл.

По UX, пишут, что в среднем у пользователя ~80 приложений, значит worst case 10/80 = 12.5% ощутимо схожи. Думаю, это может быть неприятно, ибо как по мне людям нравится разнообразие, но кому-то с привычным интерфейсом может и проще — это достойно отдельно исследования. Насчёт уведомлений не совсем понял, какова проблема получения из разных приложений?

Но вернёмся к предпосылке: «в среднем на одном девайсе 5-10 приложений из одной „коробки“» — так ли это? Увы, статистики не нашёл, но у меня коллизий совсем нет, у членов семьи тоже не обнаружил. Как понимаю, обычно White Label покупает средний и малый бизнес => аудитория довольно мала => коллизии минимальны. Поэтому, возможно, обсуждённых проблем и вовсе нет.

Единое приложение — интересная модель. Видел такое, например, у парикмахерских в ВК через YCLIENTS. Не могу сказать, почему она недостаточно популярна, но предполагаю, что может быть связано с брендом — своё приложение в маркете ощущается престижнее, что ли.

А как по вашему опыту — часто коллизии встречаются?

P.S. Цифры весьма условны, но тут цель исследовать вопрос «на порядок». И, конечно, источники выбирал под эффектом confirmation bias :) В любом случае, спасибо за интересную тему дискуссии!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.