TS
услышал
Size: a a a
2019 March 24
TS
извиняюсь
QH
RxJava есть на проекте? Можно наверное и через Runnable, но я не умею.
<sarcasm> Конечно. Как же без RxJava? Ведь единичное событие с задержкой — это стрим! </sarcasm>Ну, если иначе не умеешь, пора браться за Java Core.
QH
Добрый вечер: Такой вопрос : при нажатии на кнопку , открывается модальное окно. Как реализовать чтобы кнопка закрыть появилась через 3 секунды , и если человек на нее нажмет, окно закроет и вновь захочет его открыть - кнопка закрыть снова появлялась только через 3 секунды. ? Использую setTimeout - но кнопка появляется только 1 раз и больше не исчезает
А по делу — надо смотреть код, без него нельзя ничего сказать.
Можно закинуть вопрос куда-нибудь в @js_ru со ссылкой на Pastebin или Fiddle.
Можно закинуть вопрос куда-нибудь в @js_ru со ссылкой на Pastebin или Fiddle.
2019 April 04
SZ
Есть ли инструмент, который мокает объекты, подставляя дефолтные значения? То есть: поле
Это даже не мок получится, а инициализатор с рандомными значениями, видимо. Задача: не вводить вручную data классы для тестов.
String - будет не-null каким-нибудь "abc" и так далее. Я так понимаю, в Mockito нужно явно указывать: если запрашивается это, то возвращать вот это.Это даже не мок получится, а инициализатор с рандомными значениями, видимо. Задача: не вводить вручную data классы для тестов.
QH
Есть ли инструмент, который мокает объекты, подставляя дефолтные значения? То есть: поле
Это даже не мок получится, а инициализатор с рандомными значениями, видимо. Задача: не вводить вручную data классы для тестов.
String - будет не-null каким-нибудь "abc" и так далее. Я так понимаю, в Mockito нужно явно указывать: если запрашивается это, то возвращать вот это.Это даже не мок получится, а инициализатор с рандомными значениями, видимо. Задача: не вводить вручную data классы для тестов.
Есть, где-то видел обсуждение.
NI
Есть ли инструмент, который мокает объекты, подставляя дефолтные значения? То есть: поле
Это даже не мок получится, а инициализатор с рандомными значениями, видимо. Задача: не вводить вручную data классы для тестов.
String - будет не-null каким-нибудь "abc" и так далее. Я так понимаю, в Mockito нужно явно указывать: если запрашивается это, то возвращать вот это.Это даже не мок получится, а инициализатор с рандомными значениями, видимо. Задача: не вводить вручную data классы для тестов.
whenNew(Class.class).withAnyArguments().thenReturn(new Class(...))
2019 April 12
ИМ
Привет. Может кто-нибудь сталкивался с Android architecture components? Точнее интересует ее ViewModel. Еще точнее то, как она работает с rx. Существует класс CompositeDisposable кот. хранит в себе все disposables, например каноничный пример как все рекомендуют его использовать:
class ExampleViewModel : ViewModel() {
private val compositeDisposable = CompositeDisposable()
fun doSomething() {
val disposable = Single.just(1)
.subscribe {
//update something onNext
}
compositeDisposable.add(disposable)
}
override fun onCleared() {
compositeDisposable.clear()
}
}
почему когда я принял callback (комментарий //update something onNext) я не удаляю disposable из compositeDisposable? там же ссылка на него будет висеть вечно
class ExampleViewModel : ViewModel() {
private val compositeDisposable = CompositeDisposable()
fun doSomething() {
val disposable = Single.just(1)
.subscribe {
//update something onNext
}
compositeDisposable.add(disposable)
}
override fun onCleared() {
compositeDisposable.clear()
}
}
почему когда я принял callback (комментарий //update something onNext) я не удаляю disposable из compositeDisposable? там же ссылка на него будет висеть вечно
MI
Ты же просто так не сможешь очистить compositeDisposable в onNext :)
Резонно удалять ссылки при завершении жизненного цикла активити/фрагмента, то есть, вызывать onCleared в onDestroy. Поправьте, если не прав :)
Резонно удалять ссылки при завершении жизненного цикла активити/фрагмента, то есть, вызывать onCleared в onDestroy. Поправьте, если не прав :)
ИМ
подождите. до завершение жизненного цикла активити могла жить годами. и за это время сделать милионы вызовов
ИМ
которые останутся висеть в compositeDisposables вечно. Я сперва думал там какой WeakhashMap кот. их сам почистит, но нет, там обычный массив внутри
I
Ты же просто так не сможешь очистить compositeDisposable в onNext :)
Резонно удалять ссылки при завершении жизненного цикла активити/фрагмента, то есть, вызывать onCleared в onDestroy. Поправьте, если не прав :)
Резонно удалять ссылки при завершении жизненного цикла активити/фрагмента, то есть, вызывать onCleared в onDestroy. Поправьте, если не прав :)
onCleared вызывается автоматически, его не надо вызывать в ручную
MI
А что мешает вручную очищать его когда получил callback от viewmodel?
ИМ
то и мешает что все примеры как правильно это делать так не делают
MI
Я лично не вижу проблем в хранении compositeDisposable до окончания ЖЦ активити. Вся суть их, чтобы мы могли их отменять когда активити закрывается во время выполнения запроса во избежании утечек памяти.
ИМ
а то что они накапливаются бесконечно?
ИМ
"Вся суть их, чтобы мы могли их отменять..." - ключевое слово отменять. Т.е. те которые в прогрессе
ИМ
а после колбека их уже не надо отменять и они просто висят в памяти. Вечно