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