просто придется и на делегат тоже ссылку сохранить рядом

вот это сейчас и пытаюсь сделать.

если объект к которому нужен доступ кастомный, то можно прямо его сделать делегатом

а вот это классная идея, спасибо

лучше бы нулейбл просто сделать

да, сложновато будет

да, не, это совсем не сложно

в 1.1 появилась еще вот такая штука, возможно окажется полезной как раз для твоего случая

https://kotlinlang.org/docs/reference/delegated-properties.html#providing-a-delegate-since-11

да, не, это совсем не сложно

я говорил про вариант с ViewHolder =)

а %-)

еще вот такой вариант приходит в голову, хорош если таких значений несколько class Tmp { private val hook = Hook() private val value: String by DisposableLazy(hook) { someExpression() } fun onDispose() { hook.dispose() } }

то есть инициализация гарантируется разработчиком, дальше свойство обычный val. дальше разработчик гарантирует что не использует свойство после деинициализации. правда нужно еще иметь возможность проверить текущее состояние для пересоздания

Вроде кейс с apply/let делает то, что ты описываешь, разве нет? view: View? fun somewhere() { s?.apply { v: View -> // .... }?: throw SomeException() }

и упадет, если null, и не надо !! писать

Вроде кейс с apply/let делает то, что ты описываешь, разве нет? view: View? fun somewhere() { s?.apply { v: View -> // .... }?: throw SomeException() }

так не заработает. also надо, чтобы v: View работало

s?.let { v: View -> // .... }?: throw SomeException()

вот так заработает

тогда в let что-то нужно вернуть

ну вот var s: String? = null fun f() { s?.let { ss: String -> println("whatever") }?: throw Exception() }

ну вот var s: String? = null fun f() { s?.let { ss: String -> println("whatever") }?: throw Exception() }

а чем это лучше !!? длинее, читать тяжелее, делает тоже самое, разве нет?

там еще гарантия есть, что внутри let твой объект никто не занулит (с другого потока)

не нужно каждый раз ставить !!, обращаясь к нему

еще вот такой вариант приходит в голову, хорош если таких значений несколько class Tmp { private val hook = Hook() private val value: String by DisposableLazy(hook) { someExpression() } fun onDispose() { hook.dispose() } }

да, все это хорошо. вот только не понятно как потом переинициализировать свойство? т.е. к возможности снести надо еще иметь возможность переинициализировать перед новым использованием. а для этого вроде как нужно как-то суметь проверить disposed или нет

s = s?.apply { s + "_"} ?: throw

не нужно каждый раз ставить !!, обращаясь к нему

да, согласен. но задача как раз избавиться от любой дополнительной возни вокруг поля которое гарантировано не нул при работе с ним =)

еще вижу проблему, если несколько полей)

так, может class Holder{ val s: String = "" val s2: String = "" } var holder: Holder? = null fun f() { holder?.let { print(it.s) print(it.s2) }?: throw Exception() }

Если с делегетами что-то придумаешь, пиши, интересно посмотреть)

еще вижу проблему, если несколько полей)

да там вообще сплошные проблемы. nullable оправдан там где он есть. тут его по семантике нет, он есть только по нормам языка =)

А в kotlin android extentions разве нет штук для этого?

А в kotlin android extentions разве нет штук для этого?

а там есть что-то кроме легкого юзанья разметки?

да там вообще сплошные проблемы. nullable оправдан там где он есть. тут его по семантике нет, он есть только по нормам языка =)

Есть ещё уберпростое решение. Просто сделать нуллабл пропертю и ненулабл метод для её получения.

Почему в джаве не реализованы фичи котлин для работы с ui в андроид? Это так сложно?

Есть ещё уберпростое решение. Просто сделать нуллабл пропертю и ненулабл метод для её получения.

да, вариант неплохой. особенно если кода много, а полей мало. но вот если их много.. вот если бы можно было как макросом сразу и поле и гетер создавать одной строкой

А в kotlin android extentions разве нет штук для этого?

это штука чисто для обращения к вьюхам из лэйаута в коде. если только в недрах анко что-то есть

тогда можно эмулировать эцсамое типа такого class Wrapper<T> { private var value:T? = null operator fun invoke():T = value ?: throw IllegalStateException() fun clean() { value = null } } class Tmp { private val value = Wrapper<String>() fun someMethod() { value().substring(10) } fun onDispose() { value.clean() } }

выглядит как метод, но всё инкапсулировано во враппере

тогда можно эмулировать эцсамое типа такого class Wrapper<T> { private var value:T? = null operator fun invoke():T = value ?: throw IllegalStateException() fun clean() { value = null } } class Tmp { private val value = Wrapper<String>() fun someMethod() { value().substring(10) } fun onDispose() { value.clean() } }

вот это классно! =) не идеально, но пока ближе всего к нему =)

синтаксис метода это конечно немного странно будет в коде =)

эх, был бы доступ к делегату проперти без сохранения его отдельно..

да, и вообще это можно сделать

через рефлекшн

но я пробовал, хорошего решения всё равно не выходит

кажется я придумал простейшее решение как проверить что поле не инициализировано - нужно сделать экстеншн метод который читает его значение и ловит правильный тип эксепшена

так можно сделать один объект который предоставляет делегаты и сохраняет их у себя

сам этот объект сделать с lazy инициализацией в базовом классе фрагмента

настоятельно не рекомендую делать глобальное состояние

тогда в конкретном фрагменте все будет выглядеть идеально

настоятельно не рекомендую делать глобальное состояние

почему?

потому что это дорога в ад

что ты имеешь в виду? =) глобавльное оно же только в рамках конкретного инстанса

одним вызовом все такие поля очистятся

есть красота и удобство с одной стороны и нарушение инкапсуляции и вцелом хороших практик -- лучше чуть ужаться в первом на мой взгляд

может я тогда не понял, что ты предлагаешь

проверять что поле не инициализировано эксепшеном тоже идея на мой взгляд так себе

может я тогда не понял, что ты предлагаешь

ща покажу

class DisposablePropertyManager { private val propertyDelegates: ArrayList<RegularDisposableVar<*>> = ArrayList() fun <T : Any> disposable(): ReadWriteProperty<Any?, T> { return RegularDisposableVar<T>().apply { propertyDelegates.add(this) } } fun dispose() { for (delegate in propertyDelegates) { delegate.dispose() } } } private class RegularDisposableVar<T : Any>() : ReadWriteProperty<Any?, T> { private var value: T? = null override fun getValue(thisRef: Any?, property: KProperty<*>): T { return value ?: throw IllegalStateException("Property ${property.name} should be initialized before get.") } override fun setValue(thisRef: Any?, property: KProperty<*>, value: T) { this.value = value } fun dispose() { value = null } }

использование: private val disposableManager: DisposablePropertyManager by lazy { DisposablePropertyManager() } private val feedListAdapter: MyFeedListAdapter by disposableManager.disposable()

первую строку можно положить в базовый класс

примерно так

если в сам делегат еще навернуть лямбду как у lazy то получим ленивую инициализацию

а дальше дилемма - можно делать инициализацию всегда когда value == null

тогда в общем-то без всяких проверок эксепшенов все будет работать

только вот если что-то попутать, то вместо эксепшена получим инициализацию и последующий меморилик

а можно безусловную иницализацию не делать и кидать таки эксепшен, но тогда нужно как-то проверить что поле еще не инициализировано

как это сделать кроме как через эксепшен лаконично я пока не придумал

чота мне кажется, что черезмерная сложность для такой задачи, мы же на котлине пишем! ?

еще можно на DisposablePropertyManager сделать метод init, который либо заставит все пропет=рти инициализироваться, либо просто разрешит им это сделать лениво без эксепшена. тогда между dispose и init эксепшен будет кидаться как задумано

ERROR: S client not available

а ты понимаешь что бессмысленно делать лейзи disposableManager?

чота мне кажется, что черезмерная сложность для такой задачи, мы же на котлине пишем! ?

так а я о чем! меня тоже это все напрягает. думаю это вопрос личных предпочтений. мне как-то спокойнее положить в одно место какую-то страшную (условно) хрень, которая правильно и эффективно работает, чем видеть в каждом втором классе совершенно не нужные и корявые !!

не только потому что непонятно зачем, но и потому что он сразу инициализируется как только ты его используешь для создания другог делегата

ну я же вроде предложил пару решений для их исключения, но вцелом если в одном классе может быть много таких полей, которые надо диспозить, то вполне ок

только я бы еще из списка делегаты тоже удалял

не только потому что непонятно зачем, но и потому что он сразу инициализируется как только ты его используешь для создания другог делегата

это нужно для тех фрагментов где нет disposable полей вообще. в базовом классе будет объявлен менеджер но он не будет создан

только я бы еще из списка делегаты тоже удалял

зачем? и как они потом снова туда попадут?

а, они еще и многоразовые

а, они еще и многоразовые

ну да! фрагмент вью создал снова все работает =)

это нужно для тех фрагментов где нет disposable полей вообще. в базовом классе будет объявлен менеджер но он не будет создан

а, дело, да

ну учитывая что by lazy мы не боимся испорльзовать не вижу проблем такое использовать

работает оно просто и лежит просто в одном месте кушать не просит

не до конца чисто конечно, но имхо лучше чем ничего

да, вполне ок решение

вариант с Wrapper тоже хороший, но на мой вкус внутри кода будет уж больно необычно смотреться (как метод)

я бы наверное что-то вроде него выбрал. или с хуками, что по сути тоже самое, что предложил ты, только не надо список хранить

тоесть просто вытащить наружу хвост, чтобы за него дергать когда хочется всё очистить

тоесть просто вытащить наружу хвост, чтобы за него дергать когда хочется всё очистить

ты имеешь в виду сохранять делегат рядом?

не, я там выше присылал вариант с хуком

class Tmp { private val hook = Hook() private val value1: String by DisposableLazy(hook) { someExpression() } private val value2: String by DisposableLazy(hook) { someExpression() } fun onDispose() { hook.dispose() } }

class Tmp { private val hook = Hook() private val value1: String by DisposableLazy(hook) { someExpression() } private val value2: String by DisposableLazy(hook) { someExpression() } fun onDispose() { hook.dispose() } }

это очень похоже на мой вариант только управление инвертировано, если я правильно понимаю

Я так и сказал?

Я так и сказал?

?

=)

получилось даже круче чем я ожидал

меняешь во фрагменте lazy на disposableLazy и все - поле будет очищенно и востановлено в нужный момент жизненного цикла

больше во фрагменте никакого кода не меняется

спасибо всем кто помогал идеями!

только знакомлюсь с котлин, подскажите вот код синглтона, вызов Singleton.instance будет потокобезопасным? class Singleton private constructor(){ companion object { val instance: Singleton = Singleton() } fun fooBar(){/** Some singleton function */} }

а чем не устраивает object Singleton { fun fooBar(){/** Some singleton function */} }