не, сразу не будет. будет либо если без элементов (только oncomplete), либо более одного элемента. то есть должен быть onnext+oncomplete

значения нет это oncomplete и ни одного onnext

может тебе maybe нужен, а не single?

нет, если нет значения, его нужно дождаться

oncomplete в BehaviorSubject не придет, если его никто не заэммитит (а обычно его никто не эммитит), single() должен дожидаться первого onNext

Привет. В смысле реактивное программирование? Тут по java можно задавать вопросы?)

Вчера наблюдал странность, хотел сделать стрим, в который с помощью мержа воткнул сверху сабжект без состояния, чтоб стрим "переделывался" из обычной переменной когда я ткну сабжект. В верстке подписался потом. Так эта зараза почему то не отдавала данных никуда, сабжект тупо игнорировался. Стоило мержем к сабжекту присобачить второй источник в моем случае роутер, внезапно заработал и первый. Есть идеи что могло быть не так???

Была мысль что он подписывается в верстке позже чем я отсылаю в сабжект пинок, добавлял таймауты и ничего, потом сделал оператор share() чтоб все подписчики ловили то же значение, потом даже shareReplay() написал, чтобы держать копию и все равно ничего. Стоило в верхний мерж добавить второй источник сразу везде заработало, что не так с обычным сабжектом???

Ясно понятно.

Всем привет.

Вот типичаня ситуация, во ViewModel вы подписываетесь на Observable из БД и периодически получаете какой-то объект, допустим, UserSettings, и кладёте его в глобальную переменную, к которой вы много раз обращаетесь в коде, например, делая проверки, типо if userSettings.что-то == чему-то, когда юзер нажимает кнопку и тд.

Мой вопрос про потоки. Есть ли смысл класть UserSettings в глобальную переменную исключательно в основном потоке? (с учётом того, что все вышеописанные проверки делаются в основном потоке)

Или это не имеет большого смысла, типо тут от race condition не уйдёшь, или есть какой-то другой подход, или я, вообще, что-то упускаю?

var userSettings = UserSettings.default()

repository.getUserSettings()
  .subscribeOn(Schedulers.io())
  .observeOn(AndroidSchedulers.mainThread())
  .doOnNext { userSettings = it }

или

.observeOn(AndroidSchedulers.mainThread())

можно убрать?

если к глобальной переменной обращаешься только из основного потока, то можно observeOn, иначе - synchronized

Спасибо. А synchronized же только на метод, на переменную же valotile, по идее

Нет. Volatile - это про visibility, synchronized - это про атомарность.

ага, сейчас читаю про это как раз.

Касательно volatile, как я всё-таки понял: если есть гарантия, что только один поток изменяет переменную (Schedulers.single()), то мэйну будут видны изменения, и можно обойтись только volatile, а вот если потоков уже несколько (Schedulers.io()), то нужен synchronized set.

When is volatile Enough?
As I have mentioned earlier, if two threads are both reading and writing to a shared variable, then using the volatile keyword for that is not enough. You need to use a synchronized in that case to guarantee that the reading and writing of the variable is atomic. Reading or writing a volatile variable does not block threads reading or writing. For this to happen you must use the synchronized keyword around critical sections.

As an alternative to a synchronized block you could also use one of the many atomic data types found in the java.util.concurrent package. For instance, the AtomicLong or AtomicReference or one of the others.

Есть PublishSubject, как лучше всего реализовать емит туда 1 айтема с некоторой задержкой и c возможностью  отменить этот эмит (если задержка еще не прошла) ?

observable.timer где в сабскрайбе просто эмит на сабджект + dispose в случае отмены - первое что приходит в голову, но мб есть красивее вариант

Только не забывайте, что у вас какой-то конкретный объект (UserSettings). В данном случае volatile не поможет полноценно избежать проблем (кэширование происходит в одно место, семантика happens before соблюдается, но атомарности нету). Явно будут случаи, когда констстентность будет отсутствовать, что приводит к потенциальным гонкам.  А atomic reference не пробовали кстати?

Спасибо. Про AtomicReference читал в статьях, которые выше кидал. Он должен решать проблему