Комментарии 2
Отличный пост, но позволю себе несколько замечаний.
У такого подхода, когда у вас одна сборка для обеих экосистем, есть несколько минусов, но главный из них состоит в том, что время от времени ревью-команда гугла отклоняет сборки, содержащие хуавеевские зависимости, ссылаясь на "уязвимости", "вредоносный код" и так далее. Конечно, в таких случая HMS библиотеки оперативно обновляются чтобы соответствовать представлениям гугл о безопасном коде, но некоторое количество нервов и времени это может скушать.
Поэтому я обычно советую не тащить в сборку те зависимости, которые там не нужны а пилить на флейворы. Единственная существенная издержка это то что надо тестировать и на GMS и на HMS устройствах (а как показал ваш опыт, то и на GMS+HMS тоже). Но на самом деле по-хорошему и ваш подход тоже необходимо тестировать и там и там, я даже не особо верю, что вы этого не делаете.
Ну и про карты. Вы не стали вдаваться в детали, почему не стали в итоге интегрировать хуавеевские в финальной версии, жаль, было бы интересно узнать почему. Но даже если возникли какие-то непреодолимые сложности есть ещё один подход. Можно интегрировать те карты, которое работают и на GMS и на HMS аппаратах, те же яндексовские. Аналогичный подход можно использовать и для других библиотек.
И, кстати, спасибо за тёплые слова)
Спасибо, отвечу инлайн!
У такого подхода, когда у вас одна сборка для обеих экосистем, есть несколько минусов, но главный из них состоит в том, что время от времени ревью-команда гугла отклоняет сборки, содержащие хуавеевские зависимости, ссылаясь на "уязвимости", "вредоносный код" и так далее. Конечно, в таких случая HMS библиотеки оперативно обновляются чтобы соответствовать представлениям гугл о безопасном коде, но некоторое количество нервов и времени это может скушать.
Все-таки хочется один артефакт — так удобнее работать, ну и можно, как и говорил в статье/видео, для пользователей HMS+GMS приоритезировать HMS для каких-либо фичей
А какие еще видите минусы / риски?
Поэтому я обычно советую не тащить в сборку те зависимости, которые там не нужны а пилить на флейворы. Единственная существенная издержка это то что надо тестировать и на GMS и на HMS устройствах (а как показал ваш опыт, то и на GMS+HMS тоже). Но на самом деле по-хорошему и ваш подход тоже необходимо тестировать и там и там, я даже не особо верю, что вы этого не делаете.
У нас только смоук делается (и то не всегда), основные проверки автоматизированы. Да, для HMS-фичей они не гоняются, так как эмуляторы Huawei не может предоставить
Я, кстати не рекомендую использовать флейворы для разных вариантов кода! При включении варианта сборки остальные убираются из индекса IDE. А еще сборки идут строго друг за другом (баг тулзов наверное). Это крайне затрудняет разработку, лучше уж сделать на модулях + два различных приложения.
Ну и про карты. Вы не стали вдаваться в детали, почему не стали в итоге интегрировать хуавеевские в финальной версии, жаль, было бы интересно узнать почему. Но даже если возникли какие-то непреодолимые сложности есть ещё один подход. Можно интегрировать те карты, которое работают и на GMS и на HMS аппаратах, те же яндексовские. Аналогичный подход можно использовать и для других библиотек.
Это больше продуктовая история. Пока что сделали MVP технической командой. Если продакт посчитает необходимым добавить карты в HMS сборку, то да, будем рассматривать в том числе и кросссервисные (слово то какое придумал😃)варианты
И, кстати, спасибо за тёплые слова)
Вы крутые, так держать!
Интеграция Huawei Mobile Services со второй попытки