Внимание: задача publish почему-то не имеет явной зависимости на bundle
Так это и логично и правильно Мы собираем бандл 1 раз и потом просто паблишим его в разные сторы
туда же можно добавить ещё Galaxy Store и в будущем RuStore и не нужно под каждый собирать, а только паблишить. Гугл уже давно не возникает по поводу наличия хуавеевских зависимостей, а хуавей никогда и не возражал
Можно конечно в качестве оптимизаций для пользователя(максимум сотни килобайт) разнести это по флэйворам, но при разработки это сильно ударит по производительности билд системы, так что оно того не стоит
//for autocomplite and highlight dependencies from groovy build.gradle files
api(files(libs::class.java.superclass.protectionDomain.codeSource.location))
В груви тоже работает, но нужно однострочный хак добавить в какой-нибудь корневой модуль includedBuild'а
Но тема с проваливанием в сгенерённые классы - жиза и боль
На самом деле это было не так. У нас было обсуждение, была страничка с плюсами и минусами разных подходов и всё обсуждение длилось несколько недель, в котором приняли участие все разработчики Тинькофф.Бизнес. Но для статьи я опустил эти подробности. Видимо зря. Основная причина была в большей переиспользываемости и меньшем дублировании. На мой взгляд, библиотека получилась такой, которая позволяет это сделать.
Так как у нас есть дизайн система, то сначала ждём компоненты там, чтобы не писать одно и тоже по несколько раз в разных проектах. Но уже есть некоторые части, которые используют компоуз. Например, превью сториз в мобильном банке. Об этом был доклад на недавнем DUMP'е
а, понял.
У нас на проекте данных хранятся в объекте, который закрыт интерфейсом(LocalDataSource), за которым может быть как работа с базой, так и мапа в памяти просто. Допустим мы открыли список проектов. Нам пришла модель от бэка, где есть всё, что нам нужно для отображения. Мы её как-то обработали и передали в ScreenNameLocalDataSource. Дальше подписались на изменения этих данных в ActionCreator через соответсвующий интерактор и обновляем экран на основании этих данных.
По стейту вопрос я предусмотрел и ответил в конце статьи в "Вопросы и ответы".
Не очень понял как стейт связан с передачей объекта на следующий экран. Передать объект можно любым способом удобным вам: через интент/аргументы, через синглтон, через компонент даггера, который живёт для этих двух экранов, через базу данных и какой-то ключ экрана. Варианты зависят от потребностей и размера передаваемых данных.
Я пытался объяснить по-простому и упрощая некоторые вещи. Твои замечания верны, но такое описание сложно понять, если ты не фронтендер со стажем. В нашем, андроидном, мире всё немного по другому. Поэтому я и написал так, чтобы понятно было тем, кто никогда не видел и не слышал что такое Redux
Редьюсеры — функции, которые определяют правила обработки веток стейта
Там в начале, перед первой главой, есть эпиграф, который говорит, стейт задаёт то, что видит пользователь. Поэтому, когда я говорю, что редьюсер знает как обновить экран, я имею в виду, что он знает как обновить стейт, от которого зависит экран
да я сидел, думал, как назвать, жонглировал основными частями архитектуры и как-то буквы сложились в такое хайповое название. Мне показалось оно с одной стороны забавное, с другой стороны реально описывающее действительность. Поэтому решил оставить
Так это и логично и правильно
Мы собираем бандл 1 раз и потом просто паблишим его в разные сторы
туда же можно добавить ещё Galaxy Store и в будущем RuStore и не нужно под каждый собирать, а только паблишить. Гугл уже давно не возникает по поводу наличия хуавеевских зависимостей, а хуавей никогда и не возражал
Можно конечно в качестве оптимизаций для пользователя(максимум сотни килобайт) разнести это по флэйворам, но при разработки это сильно ударит по производительности билд системы, так что оно того не стоит
чистый, просто используется remote build cache)
Ну так то нет, не обязательно. Вот у нас есть доклад, где есть альтернативное предложение: https://www.youtube.com/watch?v=Guh3gQO4mFE
А теперь цифры c холодной сборки со скана, который мне сегодня прислал коллега с локальной машины на m1 max:
Модули:
514 projects (2 included builds) и около 1кк строк кода
7568 tasks executed in 402 projects in 12m 35s, with 2523 avoided tasks saving 14m 47.850s
Ищем ":" в поиске
Found 7568 tasks executed in 402 projects totaling 1h 21m 12.721s, with 2523 avoided tasks saving 14m 47.850s
Ищем "kapt" в поиске:
Found 300 tasks executed in 150 projects totaling 1m 51.405s, with 1 avoided task saving 2.540s
В груви тоже работает, но нужно однострочный хак добавить в какой-нибудь корневой модуль includedBuild'а
Но тема с проваливанием в сгенерённые классы - жиза и боль
На самом деле это было не так. У нас было обсуждение, была страничка с плюсами и минусами разных подходов и всё обсуждение длилось несколько недель, в котором приняли участие все разработчики Тинькофф.Бизнес. Но для статьи я опустил эти подробности. Видимо зря. Основная причина была в большей переиспользываемости и меньшем дублировании. На мой взгляд, библиотека получилась такой, которая позволяет это сделать.
Так как у нас есть дизайн система, то сначала ждём компоненты там, чтобы не писать одно и тоже по несколько раз в разных проектах. Но уже есть некоторые части, которые используют компоуз. Например, превью сториз в мобильном банке. Об этом был доклад на недавнем DUMP'е
или EBA )
а, понял.
У нас на проекте данных хранятся в объекте, который закрыт интерфейсом(LocalDataSource), за которым может быть как работа с базой, так и мапа в памяти просто. Допустим мы открыли список проектов. Нам пришла модель от бэка, где есть всё, что нам нужно для отображения. Мы её как-то обработали и передали в ScreenNameLocalDataSource. Дальше подписались на изменения этих данных в ActionCreator через соответсвующий интерактор и обновляем экран на основании этих данных.
По стейту вопрос я предусмотрел и ответил в конце статьи в "Вопросы и ответы".
Не очень понял как стейт связан с передачей объекта на следующий экран. Передать объект можно любым способом удобным вам: через интент/аргументы, через синглтон, через компонент даггера, который живёт для этих двух экранов, через базу данных и какой-то ключ экрана. Варианты зависят от потребностей и размера передаваемых данных.
Я пытался объяснить по-простому и упрощая некоторые вещи. Твои замечания верны, но такое описание сложно понять, если ты не фронтендер со стажем. В нашем, андроидном, мире всё немного по другому. Поэтому я и написал так, чтобы понятно было тем, кто никогда не видел и не слышал что такое Redux
Там в начале, перед первой главой, есть эпиграф, который говорит, стейт задаёт то, что видит пользователь. Поэтому, когда я говорю, что редьюсер знает как обновить экран, я имею в виду, что он знает как обновить стейт, от которого зависит экран