Вы правы, давно не заглядывал в исходник Lifecycle.
Только там хитрее. Там используется специальный PausingDispatcher через который проходят все события и они либо выполняются, либо если состояние lifecycle иное, то просто стопается вся очередь и копится, а потом отдаётся.
Думал, там ещё тоже самое что и с ViewModel. Гляну и её, может тоже наконец-то что-то изменилось и в ней..
Есть такое, но тут главное не путаться с "будет работать только в started-состоянии"
Лучше сказать, что стартанёт в started(created/resumed) состоянии, но cancel будет только в destroy.
Не совсем так.
StateFlow будет "знать" только о create/destroy. Загляните, например, внутрь реализации lifecycleScope.
LiveData же умеет не оповещать если в фоне..StateFlow такое сам не сможет, скойуп не закэнселится в этом случае.
Если кратко, то из коробки никак:)
Сам по себе StateFlow никак не связан с Андроид и не знает о жизненных циклах приложения.
Единственное, что может работать — если collect запускать на скоупе либо lifecycleScope либо на скоупе ViewModel. Тогда "отмена" подписки будет происходить сама на onDestroy/onCleared.
А чтобы сделать аналогично LiveData — только самим ручками, либо возможно Гугл сделает что-то с этим сам.
Ну это не только браузерная технология уже) Будет работать на любых клиентах.
И как раз буквально пару часов назад перезалил на гитхаб официальный вариант приложения под Андроид, что бы можно было строить и собирать приложение сразу из Android Studio.
4) Ну не скажу, за многие годы на маке уже стало довольно удобным то, что можно резко сделать мышкой или трекпадом вверх(и немного влево) — и я точно на меню, не надо специально целиться.
В голову приходит только использование не корневой View
Именно так и есть.
Мне это понадобилось когда пришлось сделать биндинг на корневой view кастомизированного UI для ExoPlayer. Там хитрая система с override layout в xml и прямого доступа к контролям через биндинг не будет. Т.е. как раз нужно делать биндинг через requireView().findViewById(..id..)
Можно немного улучшить. Не всегда нужно биндинг делать только через Fragment.requireView(). Иногда нужно немного кастомного поведения. Для этого можно в конструктор FragmentViewBindingProperty передавать инициализатор, который по-умолчанию будет делать то что и сейчас, а при необходимости можно изменить это поведение.
Оценивайте тенденции) Лично я вижу, что скорость принятия и адаптации корутин очень быстрая. А появление LiveData ждали очень много времени.
Rx я думаю, тоже скоро начнут забывать… А вот у Flow есть очень много шансов.
Даже с учётом экспериментального статуса уже сейчас есть начальная поддержка ЖЦ хотя бы для автоматической отписки.
А даже если появится, то будем использовать прокладку в виде еще одного Flow вместо LiveData так как хранить состояние в UseCase не всегда нужно и редко полезно.
Ну тут не очевидно, а зачем хранить промежуточное состояние в LiveData во ViewModel? Зачем этот промежуточный слой хранения? Состояние хорошо бы хранить только в репозитории, но хотя это добавляет проблему лишних цепочных преобразований данных при смене конфигурации.
Вы опять смешиваете инструменты
Я не смешиваю, просто выше была на мой взгляд не совсем верная формулировка, что LiveData переживает ЖЦ, но она не может его переживать просто так) Это контейнер, где она хранится переживает конфигурации.
Всё это есть в любой реактивщине. В Rx — всякие PublishProcessor/BehaviorProcessor и т.д.(бывшие xxxSubject)
В Flow — пока ещё ConflatedBroadcastChannel и скорый StateFlow
К тому же есть ViewModel, которая также переживает смену конфигурации и прочее.
Но мне кажется, что LiveData во ViewModel удобнее и проще
Вот тут хотелось бы развёрнуто… Просто я вижу много примеров как под копирку, что во вью слое используется LiveData и не могу понять преимущества.
А с учётом того, что Гугл уже активно пиарит и поддерживает корутины, то будет также активно пиарить и Flow(и судя по последним коммитам Flow уже выходит из стадии Experimental), а LiveData они задиприкейтят через какое-то время..
У вас HLS? Тогда это странно, с таким не сталкивался. Может быть вам "подебажить" сам HLS плейлист на предмет двух дорожек? Если есть плейлист можете прислать в личку — гляну..
Как раз наоборот это и фича наверное:)
Как вы их сгруппируете/отфильтруете — на ваше усмотрение под вашу задачу.
Например, у нас бывает задача — показывать из всего списка только русские субтитры vtt, игнорируя остальные..
А на разработчиков с каким опытом работы рассчитан вебинар? Просто по моему опыту среди российских компаний "красивость/правильность" резюме не играет особой роли когда уже есть определённый опыт 2-3 года "промышленной" разработки… А если уж и больше то достаточно просто контактов:)
Вы правы, давно не заглядывал в исходник Lifecycle.
Только там хитрее. Там используется специальный PausingDispatcher через который проходят все события и они либо выполняются, либо если состояние lifecycle иное, то просто стопается вся очередь и копится, а потом отдаётся.
Думал, там ещё тоже самое что и с ViewModel. Гляну и её, может тоже наконец-то что-то изменилось и в ней..
Есть такое, но тут главное не путаться с "будет работать только в started-состоянии"
Лучше сказать, что стартанёт в started(created/resumed) состоянии, но cancel будет только в destroy.
Не совсем так.
StateFlow будет "знать" только о create/destroy. Загляните, например, внутрь реализации lifecycleScope.
LiveData же умеет не оповещать если в фоне..StateFlow такое сам не сможет, скойуп не закэнселится в этом случае.
Если кратко, то из коробки никак:)
Сам по себе StateFlow никак не связан с Андроид и не знает о жизненных циклах приложения.
Единственное, что может работать — если collect запускать на скоупе либо lifecycleScope либо на скоупе ViewModel. Тогда "отмена" подписки будет происходить сама на onDestroy/onCleared.
А чтобы сделать аналогично LiveData — только самим ручками, либо возможно Гугл сделает что-то с этим сам.
Ну это не только браузерная технология уже) Будет работать на любых клиентах.
И как раз буквально пару часов назад перезалил на гитхаб официальный вариант приложения под Андроид, что бы можно было строить и собирать приложение сразу из Android Studio.
4) Ну не скажу, за многие годы на маке уже стало довольно удобным то, что можно резко сделать мышкой или трекпадом вверх(и немного влево) — и я точно на меню, не надо специально целиться.
У меня здесь иллюзия, что между прямоугольниками появляются маленькие светло-серые эллипсы:)
Именно так и есть.
Мне это понадобилось когда пришлось сделать биндинг на корневой view кастомизированного UI для ExoPlayer. Там хитрая система с override layout в xml и прямого доступа к контролям через биндинг не будет. Т.е. как раз нужно делать биндинг через requireView().findViewById(..id..)
Можно немного улучшить. Не всегда нужно биндинг делать только через Fragment.requireView(). Иногда нужно немного кастомного поведения. Для этого можно в конструктор FragmentViewBindingProperty передавать инициализатор, который по-умолчанию будет делать то что и сейчас, а при необходимости можно изменить это поведение.
А что тут делает Рамблер?
Оценивайте тенденции) Лично я вижу, что скорость принятия и адаптации корутин очень быстрая. А появление LiveData ждали очень много времени.
Rx я думаю, тоже скоро начнут забывать… А вот у Flow есть очень много шансов.
Даже с учётом экспериментального статуса уже сейчас есть начальная поддержка ЖЦ хотя бы для автоматической отписки.
Ну тут не очевидно, а зачем хранить промежуточное состояние в LiveData во ViewModel? Зачем этот промежуточный слой хранения? Состояние хорошо бы хранить только в репозитории, но хотя это добавляет проблему лишних цепочных преобразований данных при смене конфигурации.
Я не смешиваю, просто выше была на мой взгляд не совсем верная формулировка, что LiveData переживает ЖЦ, но она не может его переживать просто так) Это контейнер, где она хранится переживает конфигурации.
Поспорю)
Всё это есть в любой реактивщине. В Rx — всякие PublishProcessor/BehaviorProcessor и т.д.(бывшие xxxSubject)
В Flow — пока ещё ConflatedBroadcastChannel и скорый StateFlow
К тому же есть ViewModel, которая также переживает смену конфигурации и прочее.
Вот тут хотелось бы развёрнуто… Просто я вижу много примеров как под копирку, что во вью слое используется LiveData и не могу понять преимущества.
А с учётом того, что Гугл уже активно пиарит и поддерживает корутины, то будет также активно пиарить и Flow(и судя по последним коммитам Flow уже выходит из стадии Experimental), а LiveData они задиприкейтят через какое-то время..
Зачем LiveData в вашем случае? Уже есть Flow, который также работает на скоупе жизненного цикла… Как плюс — отсутсвие маппинга Flow/Rx <-> LiveData.
Нет поддержки вертикальной ориентации слайдера… и судя по исходникам даже не стали закладывать:(
У вас HLS? Тогда это странно, с таким не сталкивался. Может быть вам "подебажить" сам HLS плейлист на предмет двух дорожек? Если есть плейлист можете прислать в личку — гляну..
Как раз наоборот это и фича наверное:)
Как вы их сгруппируете/отфильтруете — на ваше усмотрение под вашу задачу.
Например, у нас бывает задача — показывать из всего списка только русские субтитры vtt, игнорируя остальные..
Как раз такая сейчас ситуация и есть у меня.
Как в примерах выше и указано я фильтрую ещё и по mimeType:
А демо плеера этого не делает, мало того он будет показывать там любые текстовые дорожки(не только субтитры)
Мм, а я думал опыт и собеседование помогает в этом) ну… окей..)
А на разработчиков с каким опытом работы рассчитан вебинар? Просто по моему опыту среди российских компаний "красивость/правильность" резюме не играет особой роли когда уже есть определённый опыт 2-3 года "промышленной" разработки… А если уж и больше то достаточно просто контактов:)