DB
У меня очень серьёзные вопросы к техническому уровню статей.
у тебя все время вопросы )))
Size: a a a
2021 March 10
АГ
Обсудили с @aasitnikov, короткий ответ - тебе нужен MutableSharedFlow. https://blog.jetbrains.com/kotlin/2020/10/kotlinx-coroutines-1-4-0-introducing-stateflow-and-sharedflow/ тут описана разница.
Большое спасибо! Завтра тогда применю его, напишу, если останутся вопросы
2021 March 11
Р
Есть фрагмент, в нем три imageView. Нужно, чтоб пользователь мог выбирать из галереи как одну картинку, так и несколько. И эти несколько картинок, то есть 3, после выбор должны отображаться в этих трех imageView. И эти же выбранные картинки будут загруженя в firebase storage. Как можно реализовать такое? Может кто то сталкивался?
L
не в тот чат вопрос
ВК
Скажите пожалуйста, как выполнить Completable.fromAction{} при подписке на функцию, которая возвращает Single?
T
abstract fun<T> fill(fillData: T)
подскажите как я могу обобщенную функцию переопределить в классе наследнике, по типу такого чтобы получилось:
override fun <Int> fill(fillData: Int)
подскажите как я могу обобщенную функцию переопределить в классе наследнике, по типу такого чтобы получилось:
override fun <Int> fill(fillData: Int)
КЖ
abstract fun<T> fill(fillData: T)
подскажите как я могу обобщенную функцию переопределить в классе наследнике, по типу такого чтобы получилось:
override fun <Int> fill(fillData: Int)
подскажите как я могу обобщенную функцию переопределить в классе наследнике, по типу такого чтобы получилось:
override fun <Int> fill(fillData: Int)
Так а в чем загвоздка?
T
Так а в чем загвоздка?
там походу Any подставляется. в общем, нет доступа к методам класса указанного в качестве обобщения
КЖ
там походу Any подставляется. в общем, нет доступа к методам класса указанного в качестве обобщения
А если класс дженериком сделать?
AL
abstract fun<T> fill(fillData: T)
подскажите как я могу обобщенную функцию переопределить в классе наследнике, по типу такого чтобы получилось:
override fun <Int> fill(fillData: Int)
подскажите как я могу обобщенную функцию переопределить в классе наследнике, по типу такого чтобы получилось:
override fun <Int> fill(fillData: Int)
Ответил в @kotlin_start , давайте без кросспостов пожалуйста
T
А если класс дженериком сделать?
не могу на уровне класса указывать. там сложная архитектура от джава классов
АГ
Обсудили с @aasitnikov, короткий ответ - тебе нужен MutableSharedFlow. https://blog.jetbrains.com/kotlin/2020/10/kotlinx-coroutines-1-4-0-introducing-stateflow-and-sharedflow/ тут описана разница.
Алексей, привет. В целом, вариант с MutableSharedFlow сработал.
Однако, я всё равно не понимаю, почему не сработал MutableStateFlow.
По логике, да, тут подходит SharedFlow, так как мы показываем не state, а серию обновлений этого state. Но ведь ситуация, если у нас просто state меняется быстро также возможна. Условно, если брать описанный в статье пример — мы можем сразу после INITIALIZED перейти в SUCCESS.
Однако, я всё равно не понимаю, почему не сработал MutableStateFlow.
По логике, да, тут подходит SharedFlow, так как мы показываем не state, а серию обновлений этого state. Но ведь ситуация, если у нас просто state меняется быстро также возможна. Условно, если брать описанный в статье пример — мы можем сразу после INITIALIZED перейти в SUCCESS.
АЕ
Алексей, привет. В целом, вариант с MutableSharedFlow сработал.
Однако, я всё равно не понимаю, почему не сработал MutableStateFlow.
По логике, да, тут подходит SharedFlow, так как мы показываем не state, а серию обновлений этого state. Но ведь ситуация, если у нас просто state меняется быстро также возможна. Условно, если брать описанный в статье пример — мы можем сразу после INITIALIZED перейти в SUCCESS.
Однако, я всё равно не понимаю, почему не сработал MutableStateFlow.
По логике, да, тут подходит SharedFlow, так как мы показываем не state, а серию обновлений этого state. Но ведь ситуация, если у нас просто state меняется быстро также возможна. Условно, если брать описанный в статье пример — мы можем сразу после INITIALIZED перейти в SUCCESS.
Вот по своему контракту StateFlow является conflated, то есть не имеет поддержки никакого backpressure, и если consumer работает медленно, или producer очень быстро - то необработанные значения просто будут скипнуты.
Глубоко объяснить мотивацию, почему сделали именно эти два вида StateFlow, я не могу, поэтому предлагаю просто принять как данность)
Глубоко объяснить мотивацию, почему сделали именно эти два вида StateFlow, я не могу, поэтому предлагаю просто принять как данность)
АЕ
Просто если вас действительно интересует только State - вам по идее не важны его промежуточные значения. Ну не успели, ну не обработали, ну и ладно)
АГ
Вот по своему контракту StateFlow является conflated, то есть не имеет поддержки никакого backpressure, и если consumer работает медленно, или producer очень быстро - то необработанные значения просто будут скипнуты.
Глубоко объяснить мотивацию, почему сделали именно эти два вида StateFlow, я не могу, поэтому предлагаю просто принять как данность)
Глубоко объяснить мотивацию, почему сделали именно эти два вида StateFlow, я не могу, поэтому предлагаю просто принять как данность)
Придётся принять, но очень интересно. Любопытно, что нет никаких стратегий для работы с backpressure.
АГ
Просто если вас действительно интересует только State - вам по идее не важны его промежуточные значения. Ну не успели, ну не обработали, ну и ладно)
По этой логике да, звучит логично
АЕ
Почему, есть, у shared flow
АГ
Почему, есть, у shared flow
Да, я про state flow)
АЕ
Да, я про state flow)
Я его воспринял как максимально производительный sharedFlow, в котором забили на backpressure ради производительности. И думаю, что практически во всех случаях правильнне использовать sharedFlow, он работает как-то интуитивно понятнее, более ожидаемо
АГ
Я его воспринял как максимально производительный sharedFlow, в котором забили на backpressure ради производительности. И думаю, что практически во всех случаях правильнне использовать sharedFlow, он работает как-то интуитивно понятнее, более ожидаемо
Да, согласен, хотя раньше нравился больше stateflow, точнее считал его более понятным