В последнее время так уже не делаем, перешли на @Parcelize.
Но он, к сожалению, не всегда существовал, а переопределять readParcel / writeParcel для каждого элемента sealed класса не очень удобно. К тому же, куча визуального мусора, так что Serializable был намного удобнее.
В случае показа фрагмента, скорее всего нужен доступ к родительскому фрагменту или активити, так что мы обычно обрабатываем такое поведение снаружи кнопки в родителе, или считаем всю кнопку за "фрагмент" (в нашем случае — RIB), тогда у нее будет доступ к нужным API.
Все правильно, так и происходит.
В описанном вами случае мы выбираем между двух зол: необходимостью апдейта всех приложений при модификации компонента или повышенной стоимостью интеграции при вливании апстрима компонента.
В первом случае проблема (частично) решается автотестами: от интеграционных на все приложение, до юнит на отдельные части. Такой подход также равномерно распределяет нагрузку между фичами.
Второй случай несколько сложнее, так как в определенный момент обновление займет у одного из разработчиков намного больше времени. В сумме это однозначно выйдет больше чем в самих фичах, учитывая потерю контекста этих апдейтов, синк с разрабами компонентов итд. Опять же, большие изменения сложнее протестировать и ревьювить.
Опять же, как и в комменте сверху, вопрос в разделении обязанностей. Как разработчик компонента, вы ответственны не только за свой компонент, но и его интеграцию во все приложения, что отражается на процессах.
На самом деле сделали, но результат получился не очень впечатляющий. Maven репозиторий работает в случаях, когда модули и библиотеки достаточно редко обновляются, в особенности если считать изменения, ломающие внешний API.
Хороший пример такой библиотеки — MVICore, она сделана один раз и мы делаем только QoL апдейты.
В нашем же случае, такие изменения происходят очень часто, что приводит к большему количеству телодвижений при каждом апдейте, особенно если такие общие модули находятся в активной разработке. К тому же, если вы меняете что-либо в общем модуле каждую неделю, вполне есть вероятность, что модуль убежит вперед от проекта приложения, и это принесет проблемы при необходимости апдейта.
В общей архитектуре нам пришлось найти баланс между свободой творчества и переиспользованием, что определенно наложило некоторые рамки. Определенно, все изменения и новые решения достаточно бурно обсуждаются, так же как и недостатки текущих подходов.
В общем, сейчас у нас команды можно разделить на две группы: одни занимаются только разработкой конкретного продукта; другие же создают компоненты (например регистрацию или чат) и внедряют их во все приложения. Несмотря на такое разделение, я бы не сказал, что у нас есть проблема про «откуп создателям», так как это не аутсорс, то есть у всех команд есть чувство ответственности и некого владения продуктом, или хотя бы его частью.
Как ни странно, мотивация всегда была. До начала строительства компонентов, когда ответственность была очень размазана, старались поделиться если не уже написанной библиотекой, то хотя бы концептом, который хорошо решал проблему. Наверно все же сказывается то, что у нас практически невозможно перекинуть вину на создателя модуля, так как разработчик сам ответственен за свои задачи и их выполнение. Если что-то пошло не так, вопросы будут скорее к тому, как не заметили косяков во время планирования, особенно если этот «крутой модуль» хорошо решает оригинальную задачу.
В текущий момент все еще проще, так как изначально ставится задача написать (вытащить) некоторый модуль, и ответственность за поддержку ложится на ответственную команду. В скоуп задач этой команды входит быть участником чужих квестов и даже (скорее всего) тащить их на себе.
При копировании списков обычно используется обычная логика из стандартной либы Котлина: элементы старого списка просто перегоняются в новый, что не влечет с собой полного копирования каждого элемента. Если же список не поменялся, мы просто кладем весь старый инстанс в новый State (в Котлине это просто copy для data class). Эти списки и их элементы обычно immutable, что позволяет легко избежать возможных проблем из-за изменений данных снаружи Reducer.
Насчет второго вопроса: ваше предположение почти верно, мы создаем новую копию State на каждый ивент, который его меняет. Если ивент ничего не поменял (например он только триггерит News или PostProcessor), то обычно State остается прежним.
Если же State изменяется слишком часто, в теории можно аггрегировать эти ивенты (например через window для RxJava), и применять их изменения пачками.
В дополнение к комментарию ANublo насчет пункта про восстановление из Bundle. Если мы держим фичу в Android компоненте (Activity/Fragment), то восстановление State возможно при создании Feature (один из параметров — initialState). Вопрос в том, что часто имеет смысл держать фичу в более глобальном контексте, привязываясь к view и иным компонентам через Binder, который умеет в Lifecycle (об этом больше во второй статье).
В случае убийства всего процесса, можно просто открыть нужный экран, при этом пройдя через инициализацию фичи заново, так как процесс мог быть убит достаточно давно.
Сам не заводил, но насчёт этого есть несколько issue на youtrack, которые лежат там несколько лет :)
Например, https://youtrack.jetbrains.com/issue/KT-21570 или https://youtrack.jetbrains.com/issue/KT-9499.
В последнее время так уже не делаем, перешли на @Parcelize.
Но он, к сожалению, не всегда существовал, а переопределять
readParcel/writeParcelдля каждого элемента sealed класса не очень удобно. К тому же, куча визуального мусора, так что Serializable был намного удобнее.В случае показа фрагмента, скорее всего нужен доступ к родительскому фрагменту или активити, так что мы обычно обрабатываем такое поведение снаружи кнопки в родителе, или считаем всю кнопку за "фрагмент" (в нашем случае — RIB), тогда у нее будет доступ к нужным API.
В описанном вами случае мы выбираем между двух зол: необходимостью апдейта всех приложений при модификации компонента или повышенной стоимостью интеграции при вливании апстрима компонента.
В первом случае проблема (частично) решается автотестами: от интеграционных на все приложение, до юнит на отдельные части. Такой подход также равномерно распределяет нагрузку между фичами.
Второй случай несколько сложнее, так как в определенный момент обновление займет у одного из разработчиков намного больше времени. В сумме это однозначно выйдет больше чем в самих фичах, учитывая потерю контекста этих апдейтов, синк с разрабами компонентов итд. Опять же, большие изменения сложнее протестировать и ревьювить.
Опять же, как и в комменте сверху, вопрос в разделении обязанностей. Как разработчик компонента, вы ответственны не только за свой компонент, но и его интеграцию во все приложения, что отражается на процессах.
Хороший пример такой библиотеки — MVICore, она сделана один раз и мы делаем только QoL апдейты.
В нашем же случае, такие изменения происходят очень часто, что приводит к большему количеству телодвижений при каждом апдейте, особенно если такие общие модули находятся в активной разработке. К тому же, если вы меняете что-либо в общем модуле каждую неделю, вполне есть вероятность, что модуль убежит вперед от проекта приложения, и это принесет проблемы при необходимости апдейта.
В общем, сейчас у нас команды можно разделить на две группы: одни занимаются только разработкой конкретного продукта; другие же создают компоненты (например регистрацию или чат) и внедряют их во все приложения. Несмотря на такое разделение, я бы не сказал, что у нас есть проблема про «откуп создателям», так как это не аутсорс, то есть у всех команд есть чувство ответственности и некого владения продуктом, или хотя бы его частью.
В текущий момент все еще проще, так как изначально ставится задача написать (вытащить) некоторый модуль, и ответственность за поддержку ложится на ответственную команду. В скоуп задач этой команды входит быть участником чужих квестов и даже (скорее всего) тащить их на себе.
Насчет второго вопроса: ваше предположение почти верно, мы создаем новую копию State на каждый ивент, который его меняет. Если ивент ничего не поменял (например он только триггерит News или PostProcessor), то обычно State остается прежним.
Если же State изменяется слишком часто, в теории можно аггрегировать эти ивенты (например через window для RxJava), и применять их изменения пачками.
В случае убийства всего процесса, можно просто открыть нужный экран, при этом пройдя через инициализацию фичи заново, так как процесс мог быть убит достаточно давно.