После полной сборки и вызова пары методов через UI(ну точнее не методов, а диалогов, через которые получались данные), которые записывали в БД, после чего нельзя было зайти.

Но тут смотрите как бизнес логика позволяет, вообще такие цепочки строить - не самая простая затея. Иногда приходится делать паблишеры горячими из-за этих сложностей, так как хочется разделять цепочку на несколько элементов

Есть вопрос. Я как-то смотрел логи в консоль при исполнении на разных потоках, у меня получалось так, что данные не успевались обрабатываться, не произойдёт ли здесь такого?. (хотя там наверное то, что первым шёл UI Thread повлияло, так как я там по итогу вызывал 3 диалога)

Нужен более конкретный пример, но это частая проблема, что цепочка может не успевать обрабатывать данные/терять их

Понял, спасибо!

Печально как-то получается, что нормально дебагом пользоваться невозможно

Там же как раз и делают кастомный request у подписки, чтобы контроллировать

Кастомный request это как я понимаю кастомный вариант генерации событий подписчикам?

И есть ещё вопрос, что можно почитать про методы в RxJava? (документация не пошла как и куча статьей (даже самая лёгкая для чтения от Badoo на Habr))

Не совсем понял. Я скорее говорил про интерфейс

public interface Subscription {
      public void request(long n);
      public void cancel();
}

>When a Subscriber first connects to a Publisher, it is given a Subscription in the Subscriber#onSubscribe method. The Subscription is arguably the most important part of the whole specification: it enables backpressure. The Subscriber uses the Subscription#request method to request more data (from n to Long.MAX_VALUE) or the Subscription#cancel method to halt processing.

Т.е при создании подписки вы можете ограничить входящий поток данных

А разве данный механизм не замедляет отправку данных от Flowable? (просто там была беда в том, что Flowable создаёт событие, после нажатия на иконку в UI (один раз), после чего в doOnNext() вызывался MaterialDialog и сразу же шло выполнение следующих doOnNext(), после чего у подписчика вызывался onNext() метод, при этом doOnNext(), который вызывался в первым(в UI потоке) не успевал выполнится, так как ждал данных от пользователя) Или данный метод может в какой-то момент в цепочке ограничить поток данных?

Хм, ну тут уж специфика вашей бизнес логики. А так не уверен, что это ограничение замедляет, скорее уменьшает back pressure (давление на flowable). На счёт проблемы с ожиданием второго потока. Не скажу точно, но вам может помочь метод в духе await, либо делать ожидание самостоятельно. Просто идея то в том, что вы специально хотите расспаралелить это выполнение. Но я не до конца уловил ваш контекст, если честно

Ну я ту логику убрал, так как не получилось сократить код(да и в целом он был бессмысленный, я просто этого не сразу понял). Касаемо того холодный или горячий Flowable был, скорее горячий, так как данные были постоянно разные и в теории данных могло одномоментно прийти очень много (но такое маловероятно, так как пользователю давался сразу же диалог, на закрытие которого как раз требовалось время сопоставимое с записью в БД)

Бессмысленный в каком плане?  
И тогда давайте уточню, а что такое employees в вашем случае?

Просто по тому коду, который представлен, вообще непонятно, о каких других действиях в другом потоке идёт речь.

А там в другом месте был код. Там постоянно по on Click передавалась view'шка и выполняласаь та самая логика. И тут employees это было временны не гейминг, сейчас это называется links (набор GitLinks' ов)

А можно увидеть весь код? Пока не уловил то, что вы хотите сделать. Можем и в личку перейти, если хотите

У меня есть фото(к сожалению на GitHub не залил и на то, чтобы найти фото и скинуть мне нужно минут 5-10) первой версии того кода, но там было без вызова MaterialDialog, но я помню где этот вызов(вызовы) был(-и).

Просто либо я не понимаю что вы делаете, либо вы делаете что-то несколько извращённое 😅

Тут до вызова observeOn(Schedulers.io()) был вызовов doOnNext() внутри которого посстепенно открывались диалоги (после каждого нажатия на positive button у диалога