V
Вроде как вообще рекомендуют явный импорты. Не только в синтетике
Size: a a a
2020 February 16
2020 February 17
K
да нигде не рекомендуют. Это гугловцы себе так настроили для андроида, a ktlint подхватил и там люди копья ломают, почему нельзя отключить: https://github.com/pinterest/ktlint/issues/48. В котлиновских правилах этой ерунды нет, по дефолту IDEA группирует и какбэ в ~18млн строк исходников самой IDEA этого не понадобилось. Был твит от Вартана, что ему так больше нравится потому что "а почему нет?". Такое...
K
мне больше интересно с практической точки зрения, кто и так и так попробовал. У меня пока что с группировкой вроде реже ломает импорты на синтетиках.
ES
да нигде не рекомендуют. Это гугловцы себе так настроили для андроида, a ktlint подхватил и там люди копья ломают, почему нельзя отключить: https://github.com/pinterest/ktlint/issues/48. В котлиновских правилах этой ерунды нет, по дефолту IDEA группирует и какбэ в ~18млн строк исходников самой IDEA этого не понадобилось. Был твит от Вартана, что ему так больше нравится потому что "а почему нет?". Такое...
я просто заигнорил это правило в editconfig для ktlint.
М
тут случай такой, были 2 livedata, в какой-то момент во фрагменте нам пришлось их объединить, потому что UI может отображать данные если в обоих есть данные
получается это нужно делать во ViewModel?
т.е. изменения UI влекут за собой изменения во ViewModel
а если завтра мы решим что нам уже не нужно объединять эти стримы...
получается это нужно делать во ViewModel?
т.е. изменения UI влекут за собой изменения во ViewModel
а если завтра мы решим что нам уже не нужно объединять эти стримы...
Вообще две лайвдаты влияющие на одну вью это плохо. Проблемы начнутся тогда, когда данные из обеих будут влиять на одну и ту же часть вью. В простонароде несоглассованость состояний. А если там еще больше лайвдат, то вешайся) самый тру подход имхо это на вью одна лайвдата описывающая полностью вью стейт (как в mvi)
Y
Вообще две лайвдаты влияющие на одну вью это плохо. Проблемы начнутся тогда, когда данные из обеих будут влиять на одну и ту же часть вью. В простонароде несоглассованость состояний. А если там еще больше лайвдат, то вешайся) самый тру подход имхо это на вью одна лайвдата описывающая полностью вью стейт (как в mvi)
Ни разу не сталкивался с несогласованностью. Две лайф даты и не должны влиять на одну часть view. А вот с подходом который вы описываете в случае с mvi проблем хватает, особенно в случае со сложной view и анимациями. Андроид из коробки не умеет в редакс, как например флаттер.
Гугл ведь не делал ограничение на число лайфдат, значит и не нужно придумывать искусственных ограничений в виде одной штуки.
Если вью знает о лайфдатах у которых есть некоторые методы трансформации, почему их нельзя использовать? Не было бы лучше чтобы вью тогда знал о неком абстрактном интерфейсе на который можно только подписаться?
Гугл ведь не делал ограничение на число лайфдат, значит и не нужно придумывать искусственных ограничений в виде одной штуки.
Если вью знает о лайфдатах у которых есть некоторые методы трансформации, почему их нельзя использовать? Не было бы лучше чтобы вью тогда знал о неком абстрактном интерфейсе на который можно только подписаться?
М
Ни разу не сталкивался с несогласованностью. Две лайф даты и не должны влиять на одну часть view. А вот с подходом который вы описываете в случае с mvi проблем хватает, особенно в случае со сложной view и анимациями. Андроид из коробки не умеет в редакс, как например флаттер.
Гугл ведь не делал ограничение на число лайфдат, значит и не нужно придумывать искусственных ограничений в виде одной штуки.
Если вью знает о лайфдатах у которых есть некоторые методы трансформации, почему их нельзя использовать? Не было бы лучше чтобы вью тогда знал о неком абстрактном интерфейсе на который можно только подписаться?
Гугл ведь не делал ограничение на число лайфдат, значит и не нужно придумывать искусственных ограничений в виде одной штуки.
Если вью знает о лайфдатах у которых есть некоторые методы трансформации, почему их нельзя использовать? Не было бы лучше чтобы вью тогда знал о неком абстрактном интерфейсе на который можно только подписаться?
А можно подробнее про кейс со сложным вью и анимациями?
М
Ни разу не сталкивался с несогласованностью. Две лайф даты и не должны влиять на одну часть view. А вот с подходом который вы описываете в случае с mvi проблем хватает, особенно в случае со сложной view и анимациями. Андроид из коробки не умеет в редакс, как например флаттер.
Гугл ведь не делал ограничение на число лайфдат, значит и не нужно придумывать искусственных ограничений в виде одной штуки.
Если вью знает о лайфдатах у которых есть некоторые методы трансформации, почему их нельзя использовать? Не было бы лучше чтобы вью тогда знал о неком абстрактном интерфейсе на который можно только подписаться?
Гугл ведь не делал ограничение на число лайфдат, значит и не нужно придумывать искусственных ограничений в виде одной штуки.
Если вью знает о лайфдатах у которых есть некоторые методы трансформации, почему их нельзя использовать? Не было бы лучше чтобы вью тогда знал о неком абстрактном интерфейсе на который можно только подписаться?
А по поводу того что гугл не делал это большой открытый вопрос на холивар))) да, он много чего не делал, что неплохо бы
Y
А можно подробнее про кейс со сложным вью и анимациями?
Ну банально позиции разных вью в разном положении и мы этим управляем через общий state. Плюс до кучи добавляем восстановление из бэка
М
Ну банально позиции разных вью в разном положении и мы этим управляем через общий state. Плюс до кучи добавляем восстановление из бэка
Это типа server driven ui?
Y
Это типа server driven ui?
Ну почему же, обычный ui
М
Хотя не суть. А какая проблема, ресайклер +diff utils и погнали?
Y
Анимации сводятся не только к спискам и ресайклеру)
М
Анимации сводятся не только к спискам и ресайклеру)
Верю, но не могу пока представить, есть примерчик, чтоб одна лайфдата на вью встала боком?
Y
Ладно, я думаю эта тема немного оффтоп для данного чата.
М
Почему, тема про лайвдату) просто рили интересен кейс
Y
На словах просто так не расскажешь. Можете представить интерфейс в игре, подсказки анамированные, да все что угодно.
ST
А просто смержить лайфдаты и пушить в юай, не? Мне кажется лучше чем две лайфдаты
ST
да нигде не рекомендуют. Это гугловцы себе так настроили для андроида, a ktlint подхватил и там люди копья ломают, почему нельзя отключить: https://github.com/pinterest/ktlint/issues/48. В котлиновских правилах этой ерунды нет, по дефолту IDEA группирует и какбэ в ~18млн строк исходников самой IDEA этого не понадобилось. Был твит от Вартана, что ему так больше нравится потому что "а почему нет?". Такое...
На сколько помню, после релиза 5ой джавы это все и пошло. Компилятору вообще пофиг. Единственное для меня неудобства вызывает звёздочка только когда сорцы в вебе или саблайме смотришь, а так вообще пофиг. )
K
к топику выше, ушёл от множественных лайв дат к одной и стало намного лучше. Код линейный, простой. Куча отдельных лайвдат само по себе выглядит "тяжело", а если их комбинировать между собой, то это прямой путь в медиаторы и потом в ад. Все трансформации лучше делать ДО лайвдаты, штуками, которые для этого предназначены.