Как стать автором
Обновить
36
0
Анатолий Варивончик @ANublo

Android developer

Отправить сообщение

Возможно автору будет интересно посмотреть на 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 и находится абсолютно вся бизнес-логика.
Вы можете посмотреть репозиторий на Github, в нём есть пример небольшого приложения:
github.com/badoo/MVICore/blob/master/documentation/demoproject.md
Да, ни о какой эффективности в этом коде не стоит говорить. Хотелось показать то, что мне кажется идиоматическим подходом.
Ни в коем случае. На мой взгляд хаскель гораздо глубок и интересен.
Я попытался взять то, что мне больше всего понравилось в хаскеле и применить к Котлину. Подумал, что может кого-нибудь заинтересует взглянуть на хаскель, но похоже что я как-то неудачно это преподнёс.
Согласен, ленивые списки просто волшебные.
Да, перевод. В начале статьи указана ссылка на оригинал. Спасибо за стилистическое замечание.
Публикация через build скрипт в фабрик — здорово. Была такая идея, однако я не нашёл тогда нормального описания + подумал, что если мы захотим некоторые сборки публиковать в Fabric, а не которые нет или, например, нам надо публиковать для разных групп тестировщиков, то это проще настроить в Jenkins. Однако, я уверен, если пошаманить немного, то и ваш вариант вполне можно настроить под конкретные нужды удобно.

И укажите в примере кода, какой плагин надо подключить, чтобы это заработало.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность