Возможно автору будет интересно посмотреть на characorder.
Пальцы не нужно убирать с клавиш. Каждая клавиша имеет 4 варианта нажатия. Можно нажимать все символы одновременно и получать готовые корды. По заверениям разработчиков можно комфортно набирать 250 слов в минуту.
Сам смотрю на эту клавиатуру, но купить пока не созрел, поэтому личного опыта нету.
MVICore выступает базовым инструментов на поверх которого строятся более сложные решения. Для простых экранов достаточно одной фичи на экран, которая держит всю логику. Из минусов этого подхода — мы не сможем переиспользовать какую-то более мелкую часть фичи в другом контексте.
В данный момент мы используем компоненты (RIBs), у которых есть чёткий контракт взаимодействия, внутри которых находится фича, которая содержит нужную бизнес логику.
Я распишу на примере такого компонента, где есть коммуникация между рибами.
1. Компонент, который позволяет выбрать элемент из списка и сообщить о выбранном элементе родителю.
2. Компонент, который отображает ввод номера телефона вместе со страной (с возможностью сменить страну на другую)
3. Компонент, который связывает эти 2. Сообщает о том, что 2ой хочет выбрать элемент, возвращает выбранный элемент из 1ого компонента 2ому.
Мы можем заменить рибы на фрагменты и добьёмся того же.
Допустим у вас на экране одновременно отображаются 2 фрагмента, которые позволяют выбрать страну на первом фрагменте, и она отобразится на 2ом фрагменте. В таком случае у нас есть 2 независимые ничего не знающие друг о друге фичи (которые живут внутри фрагментов) и некий родитель, который их связывает между собой.
Добрый день!
Да, весь новый код сейчас пишем на Kotlin.
Используем MVI и в частности нашу библиотеку MVICore и в связке с ней используем RIBs.
Хайринг ивенты в ближайшее время не планируются. Расширение команды планируется, но
конкретных планов по офисам пока нету.
В этом решении есть сильные отличия от EventBus за счёт чётких контрактов по которым работает компонент. Так ведь можно и концепцию коллбэков описать как EventBus)
Есть дополнительные плюсы у использования интерфейсов, кроме простоты подмены.
Чёткий контракт, по которому видно каким образом работает компонент.
Гарантированное отсутствие проблем в тестах, когда будем мокать эту зависимость.
Но ваше замечание тоже валидно и имеет право на жизнь.
Стоит избегать преждевременных оптимизаций. Иначе с таким подходом стоит не использовать никакие библиотеки наподобие rxJava и потом не найти разработчиков на поддержку данного проекта.
Так что мы пользуемся подходом написания приложения в едином стиле и переписываем какие-то куски кода, когда профайлер демонстрирует проблемы.
Я не совсем понял ваш комментарий про EventBus, если распишите подробнее свою мысль, постараюсь ответить.
На счёт коллбэков.
Это как раз достигается с помощью input/output подхода. Сейчас приведу упрощённый пример.
У вас есть компонент, который логинит юзера в приложение.
В обычном сценарии, вы вызываете метод и либо регистрируете заранее коллбэк, либо через rx цепочку получаете результат.
В подходе с компонентами в виде input/output выглядит примерно следующим образом:
interface LoginComponent {
interface Dependency {
fun input(): ObservableSource<Input>
fun output(): Consumer<Output>
}
sealed class Input {
object Login: Input()
}
sealed class Output {
object Success: Output()
object Failed: Output()
}
}
И вы просто подписываетесь на output, который этот компонент возвращает.
Тогда после отправки события Login вы получите результаты через output.
Компоненты такого уровня мы не делаем, это упрощённый пример, чтобы ответить на вопрос.
1. Мы можем инициализировать фичу с уже необходимым нам состоянием. При уничтожении фичи вы кладетё в Bundle её текущее состояние, а потом создаёте с уже готовым состоянием.
На данный момент мы используем TimeCapsule, однако есть некоторые концептуальные проблемы связанные с ним и возможно в будущем будет выработан другой подход.
2. Держать списки в State это нормальная практика. Ребята из чата встретились с этой проблемой когда переписывали его на MVICore. Для решения они дописали небольшое расширение, чтобы view получало одновременно пару из (viewModel, previousViewModel?). В таком случае список обновлялся только в том случае, если они отличались в моделях. Ну и собственно если список меняется, то его в любом случае придётся прогонять через DiffUtil, чтобы показать пользователю.
Если сформулировать кратко: мы хотим обновлять UI только тогда, когда он действительно меняется. Этот вопрос вынесен на обсуждения, чтобы найти подход, который покроет все необходимые кейсы, как только он будет найден — решение появится в библиотеке.
3. Вы верно поняли. В Feature и находится абсолютно вся бизнес-логика.
Я попытался взять то, что мне больше всего понравилось в хаскеле и применить к Котлину. Подумал, что может кого-нибудь заинтересует взглянуть на хаскель, но похоже что я как-то неудачно это преподнёс.
Согласен, ленивые списки просто волшебные.
Публикация через build скрипт в фабрик — здорово. Была такая идея, однако я не нашёл тогда нормального описания + подумал, что если мы захотим некоторые сборки публиковать в Fabric, а не которые нет или, например, нам надо публиковать для разных групп тестировщиков, то это проще настроить в Jenkins. Однако, я уверен, если пошаманить немного, то и ваш вариант вполне можно настроить под конкретные нужды удобно.
И укажите в примере кода, какой плагин надо подключить, чтобы это заработало.
Возможно автору будет интересно посмотреть на characorder.
Пальцы не нужно убирать с клавиш. Каждая клавиша имеет 4 варианта нажатия. Можно нажимать все символы одновременно и получать готовые корды. По заверениям разработчиков можно комфортно набирать 250 слов в минуту.
Сам смотрю на эту клавиатуру, но купить пока не созрел, поэтому личного опыта нету.
В данный момент мы используем компоненты (RIBs), у которых есть чёткий контракт взаимодействия, внутри которых находится фича, которая содержит нужную бизнес логику.
Я распишу на примере такого компонента, где есть коммуникация между рибами.
1. Компонент, который позволяет выбрать элемент из списка и сообщить о выбранном элементе родителю.
2. Компонент, который отображает ввод номера телефона вместе со страной (с возможностью сменить страну на другую)
3. Компонент, который связывает эти 2. Сообщает о том, что 2ой хочет выбрать элемент, возвращает выбранный элемент из 1ого компонента 2ому.
Мы можем заменить рибы на фрагменты и добьёмся того же.
Допустим у вас на экране одновременно отображаются 2 фрагмента, которые позволяют выбрать страну на первом фрагменте, и она отобразится на 2ом фрагменте. В таком случае у нас есть 2 независимые ничего не знающие друг о друге фичи (которые живут внутри фрагментов) и некий родитель, который их связывает между собой.
Да, весь новый код сейчас пишем на Kotlin.
Используем MVI и в частности нашу библиотеку MVICore и в связке с ней используем RIBs.
Хайринг ивенты в ближайшее время не планируются. Расширение команды планируется, но
конкретных планов по офисам пока нету.
Чёткий контракт, по которому видно каким образом работает компонент.
Гарантированное отсутствие проблем в тестах, когда будем мокать эту зависимость.
Но ваше замечание тоже валидно и имеет право на жизнь.
Так что мы пользуемся подходом написания приложения в едином стиле и переписываем какие-то куски кода, когда профайлер демонстрирует проблемы.
На счёт коллбэков.
Это как раз достигается с помощью input/output подхода. Сейчас приведу упрощённый пример.
У вас есть компонент, который логинит юзера в приложение.
В обычном сценарии, вы вызываете метод и либо регистрируете заранее коллбэк, либо через rx цепочку получаете результат.
В подходе с компонентами в виде input/output выглядит примерно следующим образом:
И вы просто подписываетесь на output, который этот компонент возвращает.
Тогда после отправки события Login вы получите результаты через output.
Компоненты такого уровня мы не делаем, это упрощённый пример, чтобы ответить на вопрос.
И кроме этого у этих задач есть и другие решения.
А «правильность» сильно зависит от компании и ситуации.
Пока этой поддержки нету, но вопрос рассматривается
На данный момент мы используем TimeCapsule, однако есть некоторые концептуальные проблемы связанные с ним и возможно в будущем будет выработан другой подход.
2. Держать списки в State это нормальная практика. Ребята из чата встретились с этой проблемой когда переписывали его на MVICore. Для решения они дописали небольшое расширение, чтобы view получало одновременно пару из (viewModel, previousViewModel?). В таком случае список обновлялся только в том случае, если они отличались в моделях. Ну и собственно если список меняется, то его в любом случае придётся прогонять через DiffUtil, чтобы показать пользователю.
Если сформулировать кратко: мы хотим обновлять UI только тогда, когда он действительно меняется. Этот вопрос вынесен на обсуждения, чтобы найти подход, который покроет все необходимые кейсы, как только он будет найден — решение появится в библиотеке.
3. Вы верно поняли. В Feature и находится абсолютно вся бизнес-логика.
github.com/badoo/MVICore/blob/master/documentation/demoproject.md
Согласен, ленивые списки просто волшебные.
И укажите в примере кода, какой плагин надо подключить, чтобы это заработало.