Комментарии 12
Тоже делал когда-то подобное. Вставлю свои 5 копеек:
1) Flavors. Всё хорошо когда flavor один на приложение. А у нас было так, что у некоторых приложений были свои дополнительные "подтипы". Тут начинаются приколы, что кол-во комбинации вырастает значительно.
2) Конфиги. У серверного JSON есть ещё преимущество — сразу feature toggle получается можно использовать.
3) Ничего не рассказали о особых кастомизациях под заказчика? Были ли они у вас? Какой процесс был? Бывало ли так, что один из заказчиков хотел "общую" фичу полностью по-другому?
Спасибо за contribution в тему!
1) Жёстко. А сколько примерно приложений было, до 100? Были проблемы с поддержкой из-за громады комбинаций?
2) +, тоже об этом думал.
3) О, крутой вопрос. В статье был похожий момент в пункте 2.2 в контексте цветов, но там надо было с дизайнером внутри команды договориться. С заказчиком помню случай, когда нужна была оплата апгрейда карты лояльности. Мы исследовали её популярность, оказалось, что это узкая тема, поэтому решили не встраивать в общий проект. Делать как кастом для одного flavor тоже не стали — на мой взгляд, если позволять такое, то будет сложно поддерживать код: придётся чекать, что новые фичи не конфликтуют с "особенными" + править "уникальные" баги. В итоге порешали засчёт бэкенда заказчика, на их стороне сервер получал события от нашей системы и проводил оплату боковым путём :)
А как у вас было с кастомами?
В статье совсем ничего не сказано про тестирование.
Вы же не только xml меняете, но и кодовую базу
Как устроено, много ли версий приходится проверять? Есть ли регресс и если да, как много времени занимает?
Увы, не могу точно ответить на вопросы, ибо в деталях этим не занимался. Передал коллегам, возможно, позже раскроют тему шире :)
Что знаю: так как фичи стандартизированы, чисто логически достаточно проверить все комбинации параметров. Это можно сделать на нескольких сборках, а можно даже выбрать одну и подстраивать её конфиг. Т.е. все приложения смысла проверять не вижу, разве что ребрендинг UI посмотреть.
Если взять ещё шире, ощутимое количество багов превентируем unit-тестами: покрыли слой бизнес-логики и нетривиальные «чистые» классы из ui.
Как оптимизатор я душой чувствую «избыточные» мегабайты, но как практик люблю расчёт. Представим, что мы в мире, где в среднем у пользователя 5-10 коробочных приложений. При весе одного 5-10 МБ (Лояка) и среднем объёме памяти смартфонов ~68 ГБ избыток будет ~100 МБ — как по мне, это незначительно. Хорошо бы видеть проценты объёма по пользователям, но такого не нашёл.
По UX, пишут, что в среднем у пользователя ~80 приложений, значит worst case 10/80 = 12.5% ощутимо схожи. Думаю, это может быть неприятно, ибо как по мне людям нравится разнообразие, но кому-то с привычным интерфейсом может и проще — это достойно отдельно исследования. Насчёт уведомлений не совсем понял, какова проблема получения из разных приложений?
Но вернёмся к предпосылке: «в среднем на одном девайсе 5-10 приложений из одной „коробки“» — так ли это? Увы, статистики не нашёл, но у меня коллизий совсем нет, у членов семьи тоже не обнаружил. Как понимаю, обычно White Label покупает средний и малый бизнес => аудитория довольно мала => коллизии минимальны. Поэтому, возможно, обсуждённых проблем и вовсе нет.
Единое приложение — интересная модель. Видел такое, например, у парикмахерских в ВК через YCLIENTS. Не могу сказать, почему она недостаточно популярна, но предполагаю, что может быть связано с брендом — своё приложение в маркете ощущается престижнее, что ли.
А как по вашему опыту — часто коллизии встречаются?
P.S. Цифры весьма условны, но тут цель исследовать вопрос «на порядок». И, конечно, источники выбирал под эффектом confirmation bias :) В любом случае, спасибо за интересную тему дискуссии!
Системный гайд по созданию White Label android-приложений