М
Надеюсь, все понимают, что это идеальный пример того, как делать не надо.
Почему?
Size: a a a
2020 April 20
ЯН
Надеюсь, все понимают, что это идеальный пример того, как делать не надо.
+почему
QH
Почему?
QH
потому что нужно хоть немножечко представлять, как работает инструмент, которым пользуешься
QH
в
by lazy хорошо заворачивать какое-нибудь IO. А в случае с findViewById, сам lazy оказывается дороже, чем непосредственная инициализация в onCreateЯН
1 проблема только в фрагментах, в которых вью пересоздаётся
2 проблема syncronized решается передачей в lazy флага NONE
2 проблема syncronized решается передачей в lazy флага NONE
ЯН
в
by lazy хорошо заворачивать какое-нибудь IO. А в случае с findViewById, сам lazy оказывается дороже, чем непосредственная инициализация в onCreate
и вообще можно свой аналог написать
QH
1 проблема только в фрагментах, в которых вью пересоздаётся
2 проблема syncronized решается передачей в lazy флага NONE
2 проблема syncronized решается передачей в lazy флага NONE
первая — это какая? synchronized решается, но получается слишком длинно. А анонимный класс и дорогой объект проперти остаются.
QH
можно, но в нём есть пара багов
ЯН
можно, но в нём есть пара багов
могу только один предложить
не, если использовать только внутри других View, то не вижу багов
не, если использовать только внутри других View, то не вижу багов
DE
findViewById может null вернуть
AD
привет! при
или… может, этого не бывает на реальных девайсах?
Don’t Keep Activities = true результаты после startActivityForResult не долетают до вызывающего экрана. есть ли какой-то способ это починить?или… может, этого не бывает на реальных девайсах?
ЯН
findViewById может null вернуть
если там нул, значит разраб накосячил и пусть делает так, чтобы там не было нула
QH
0. Очередной indirection с прыжками по указателям. Впрочем, у стокового lazy та же проблема.
1. Если вьюха опциональная, то оно всю жизнь будет считать себя неинициализированным и на каждый get снова искать её.
2. Запись ссылки на каждое чтение (записи ссылок дороже, чем записи примитивов, из-за write-барьеров)
3. Как озвучил Денис, тип заявлен как не-нуллабельный, а по факту...
1. Если вьюха опциональная, то оно всю жизнь будет считать себя неинициализированным и на каждый get снова искать её.
2. Запись ссылки на каждое чтение (записи ссылок дороже, чем записи примитивов, из-за write-барьеров)
3. Как озвучил Денис, тип заявлен как не-нуллабельный, а по факту...
ЯН
0. Очередной indirection с прыжками по указателям. Впрочем, у стокового lazy та же проблема.
1. Если вьюха опциональная, то оно всю жизнь будет считать себя неинициализированным и на каждый get снова искать её.
2. Запись ссылки на каждое чтение (записи ссылок дороже, чем записи примитивов, из-за write-барьеров)
3. Как озвучил Денис, тип заявлен как не-нуллабельный, а по факту...
1. Если вьюха опциональная, то оно всю жизнь будет считать себя неинициализированным и на каждый get снова искать её.
2. Запись ссылки на каждое чтение (записи ссылок дороже, чем записи примитивов, из-за write-барьеров)
3. Как озвучил Денис, тип заявлен как не-нуллабельный, а по факту...
1 вот тут не понял, тут либо инициализация не нулом либо исключение
2 помоему это мелочи, мы же не на с++ драйвера пишем)
2 помоему это мелочи, мы же не на с++ драйвера пишем)
DE
а чем это лучше котлиновского lazy?
ЯН
1 вот тут не понял, тут либо инициализация не нулом либо исключение
2 помоему это мелочи, мы же не на с++ драйвера пишем)
2 помоему это мелочи, мы же не на с++ драйвера пишем)
чё по факту? чё? я как разработчек должен позаботиться о том, чтобы вьюхи, которые я ищу, были не нул, иначе значит я где-то накосячил и должен получить в лоб исключение!
ЯН
потому что кейсов, когда вью опциональна лично в моём проекте нет, на работе в компании в одном только месте
QH
чё по факту: опа нихуя. Ты удалил гланды через анус, получилось так себе.
ЯН
зачем предусматривать null, если должно быть не null, а его наличие == косяк разраба?