[Перевод] Строим систему реактивных компонентов с помощью Kotlin20.11.2018 19:32

Всем привет!

Меня зовут Анатолий Варивончик, я Android-разработчик Badoo. Сегодня я поделюсь с вами переводом второй части статьи моего коллеги Zsolt Kocsi о реализации MVI, которую мы ежедневно используем в процессе разработки. Первая часть здесь.

Чего мы хотим и как мы это сделаем

В первой части статьи мы познакомились с Features, центральными элементами MVICore, которые можно переиспользовать. Они могут обладать максимально простой структурой и включать всего один Reducer, а могут стать полнофункциональным средством для управления асинхронными задачами, событиями и многим другим.

Каждая Feature отслеживаема — есть возможность подписаться на изменения её состояния и получать уведомления об этом. При этом Feature можно подписать на источник ввода. И в этом есть смысл, ведь с включением Rx в кодовую базу у нас и так появилось множество наблюдаемых объектов и подписок на самых разных уровнях.

Именно в связи с увеличением количества реактивных компонентов пришло время поразмышлять о том, что мы имеем и можно ли сделать систему ещё лучше.
Нам предстоит ответить на три вопроса:

1. Какие элементы следует использовать при добавлении новых реактивных компонентов?
   
2. Какой способ управления подписками самый простой?
   
3. Можно ли абстрагироваться от управления жизненным циклом / необходимости очищать подписки, чтобы избежать утечек памяти? Иными словами, можем ли мы отделить связывание компонентов от управления подписками?
   

В этой части статьи мы рассмотрим основы и преимущества построения системы при помощи реактивных компонентов и увидим, как Kotlin помогает в этом.

Основные элементы

К тому моменту, когда мы подошли к работе над дизайном и стандартизацией наших Features, мы уже перепробовали множество различных подходов и решили, что Features будут выполнены в форме реактивных компонентов. Сначала мы сосредоточились на главных интерфейсах. Прежде всего нам нужно было определиться с типами входных и выходных данных.

Мы рассуждали следующим образом:

• Не будем изобретать велосипед — посмотрим, какие интерфейсы уже существуют.
  
• Так как мы уже используем библиотеку RxJava, есть смысл обратиться к её базовым интерфейсам.
  
• Количество интерфейсов должно быть сведено к минимуму.
  

В результате мы решили использовать ObservableSource<Т> для вывода и Consumer<Т> для ввода. Почему не Observable/Observer, спросите вы. Observable — абстрактный класс, от которого вам нужно отнаследоваться, а ObservableSource — реализуемый вами интерфейс, полностью удовлетворяющий потребность в реализации реактивного протокола.

package io.reactivex;

import io.reactivex.annotations.*;

/**
 * Represents a basic, non-backpressured {@link Observable} source base interface,
 * consumable via an {@link Observer}.
 *
 * @param  the element type
 * @since 2.0
 */
public interface ObservableSource {

    /**
     * Subscribes the given Observer to this ObservableSource instance.
     * @param observer the Observer, not null
     * @throws NullPointerException if {@code observer} is null
     */
    void subscribe(@NonNull Observer observer);
}

Observer, первый приходящий на ум интерфейс, реализует четыре метода: onSubscribe, onNext, onError и onComplete. Стремясь максимально упростить протокол, мы предпочли ему Consumer<Т>, который принимает новые элементы с помощью одного-единственного метода. Если бы мы выбрали Observer, то оставшиеся методы чаще всего были бы избыточными либо работали бы иначе (например, нам хотелось представить ошибки как часть состояния (State), а не как исключения, и уж точно не прерывать поток).

/**
 * A functional interface (callback) that accepts a single value.
 * @param  the value type
 */
public interface Consumer {
    /**
     * Consume the given value.
     * @param t the value
     * @throws Exception on error
     */
    void accept(T t) throws Exception;
}

Итак, у нас есть два интерфейса, каждый из которых содержит по одному методу. Теперь мы можем связать их, подписав Consumer<Т> на ObservableSource<Т>. Последний принимает только экземпляры Observer<Т>, но мы можем обернуть его в Observable<Т>, который подписан на Consumer<Т>:

val output: ObservableSource = Observable.just("item1", "item2", "item3")
val input: Consumer = Consumer { System.out.println(it) }
val disposable = Observable.wrap(output).subscribe(input)

(К счастью,  функция .wrap (output) не создаёт новый объект если output уже является  Observable<Т>).

Возможно, вы помните, что компонент Feature из первой части статьи использовал входные данные типа Wish (соответствует Intent из Model-View-Intent) и выходные данные типа State, а потому может находиться с обеих сторон связки:

// Wishes -> Feature
val wishes: ObservableSource = Observable.just(Wish.SomeWish)
val feature: Consumer = SomeFeature()
val disposable = Observable.wrap(wishes).subscribe(feature)

// Feature -> State consumer
val feature: ObservableSource = SomeFeature()
val logger: Consumer = Consumer { System.out.println(it) }
val disposable = Observable.wrap(feature).subscribe(logger)

Такое связывание Consumer и Producer уже выглядит достаточно просто, но существует ещё более лёгкий способ, при котором не нужно ни создавать подписки вручную, ни отменять их.

Представляем Binder.

Связывание «на стероидах»

MVICore содержит класс под названием Binder, который предоставляет простой API для управления Rx-подписками и обладает целым рядом крутых возможностей.

Зачем он нужен?

• Создание связывания путём подписки входных данных на выходные.
  
• Возможность отписки по завершении жизненного цикла (когда он является абстрактным понятием и не имеет никакого отношения к Android).
  
• Бонус: Binder позволяет добавлять промежуточные объекты, например, для ведения лога или time-travel-отладки.
  

Вместо того чтобы подписываться вручную, можно переписать приведённые выше примеры следующим образом:

val binder = Binder()
binder.bind(wishes to feature)
binder.bind(feature to logger)

Благодаря Kotlin всё выглядит очень просто.

Эти примеры работают, если тип входных и выходных данных совпадает. Но что, если это не так? Реализовав функцию расширения, мы можем сделать трансформацию автоматической:

val output: ObservableSource = TODO()
val input: Consumer = TODO()
val transformer: (A) -> B = TODO()

binder.bind(output to input using transformer)

val binder = Binder()

val binder = Binder(lifecycle)

interface Lifecycle : ObservableSource {

   enum class Event {
       BEGIN,
       END
   }

   // Remainder omitted
}

val output: PublishSubject = PublishSubject.create()
val input: Consumer = Consumer { System.out.println(it) }

val lifecycle = ManualLifecycle()
val binder = Binder(lifecycle)

binder.bind(output to input)

output.onNext("1")
lifecycle.begin()
output.onNext("2")
output.onNext("3")
lifecycle.end()
output.onNext("4")
lifecycle.begin()
output.onNext("5")
output.onNext("6")
lifecycle.end()
output.onNext("7")

// will print:
// 2
// 3
// 5
// 6

fun createBinderForActivity(activity: AppCompatActivity) = Binder(
    CreateDestroyBinderLifecycle(activity.lifecycle)
)

with(binder) {
    bind(feature to view using stateToViewModelTransformer)
    bind(view to feature using uiEventToWishTransformer)
    bind(view to analyticsTracker)
}