Pull to refresh

Comments 13

Спасибо за статью. В Вашем примере Observable для SearchView будет не совсем корректно работать. Вы на него подписываетесь в onCreate(), но при срабатывании onQueryTextSubmit у Вас произойдет отписка, так как вызовется onComplete. Получается, что повторный поиск не будет работать. Чтобы повторный поиск работал, нужно избавиться от subject.onComplete();
Спасибо за замечание. Согласен с этим, добавил информацию в статью.
В целом, использование subject может вести к неочевидным проблемам. Для создания я бы порекомендовал росмотреть на Observable.create, тем более, что там есть emitter, которому можно установить действие при завершении (полезно чтобы снять TextWatcher) например. Здесь, впрочем, появится нюанс: нужно будет правильно переключить потоки, чтобы тело create выполнилось на главном потоке.
Это перевод статьи, поэтому правки я не вносил в содержание. Но хотелось бы понять о каких конкретно возможных неочевидных проблемах идет речь?
Присоеднюсь к BFS, не стоит использовать Subject, он существует только для 1 цели: соединять императивный стиль с реактивным. По сути, он только для легаси подходит. Поэтому, да, лучше Observable.create(). Для подробностей посмотрите доклад Матвея Малькова — Art Of Rx, учитывая что вы андроид разработчик, вам это будет полезно)
И второй момент, поиск это ровно тот кейс, когда нужно думать о Backpressure, а поскольку практически все сегодня используют Rx2, то там эта проблема решена с помощью Flowable, и лучше этот кейс зарефакторить на него.
Спасибо за рекомендацию доклада. Добавлю ваше замечание к статье.
Спасибо, отличная статья, а еще лучше комментарии ).
Не являюсь android-разработчиком, но по-моему из-за subscribeOn(Schedulers.io()) установка listener-а на поле ввода будет происходить не в главном потоке
Насколько я знаю, subscribeOn() указывает в какой поток наблюдаемый источник (в нашем случае subject внутри listener поля ввода) будет передавать создаваемые observable элементы. То есть событие происходит в UI потоке, затем его отлавливает listener в этом же потоке, далее subject внутри listener создаёт событие (onNext()), а возвращаемый observable элемент уже попадает в поток IO.
Мне почему-то кажется что прав kpcb.
subscribeOn указывает поток в котором будет происходить подписка. И во время подписки вы создаете слушатель.
Слушатель в UI потоке будет дергать subject.onNext(). и возвращаемый observable будет тоже получать событие в UI потоке.
Но дальше у вас идет метод debounce. Это особенный метод, который возвращает observable, события которого будут производиться в computation sheduler. (Scheduler можно изменить — посмотрите перегрузку метода debounce).
Проверил. Subject.onNext() отрабатывает в UI потоке, а Debounce() уже в Computation. Спасибо за внимательность.

Скажите а вам не надоело пользоваться анонимными классами? На дворе вроде конец 2017 и даже андроид уже более или менее из коробки поддерживает ламбда функции.

Я бы тоже воспользовался лямбдами и/или ссылками на методы, а использование if для возврата булево значения — бредовая идея. Но это перевод и поэтому я не стал лезть в пример кода автора оригинала.
Sign up to leave a comment.

Articles