Но такие вопросы лучше в старте задавать

👍

не дает this@ кроме уже самой extension function. Мне бы доступ к функциям ListView

Жми энтер

Я идиот. Спасибо

Тебе нужен был this скоупа экстеншена. А там приемник как раз инстанс листа

👍👍👍

Использую mockitokotlin2 и runBlockingTest из kotlinx-coroutines-test
Если в тестируемом методе подменять диспетчер IO на Unconfined все работает, но с IO нет.
Какие нибудь еще есть подходы, помимо создания интерфейса, который будет подменять все диспетчеры в тестах? Что то вроде

Dispatchers.setMain(Dispatchers.Unconfined)

только для IO

Добрый день. А есть ли для IDEA инспекция, позволяющая проверить, что объекты с function type были использованы (присвоены переменной/свойству, переданы как параметр в функцию или вызваны)?
Например:

fun f(): () -> Unit {
    return { println("f") }
}

fun main() {
    f() // должно написать предупреждение, что результат вызова f не был использован
}

А подскажите по кодстилю.

Есть 3 класса:
GeneralErrorHandler(private val onFailure: ((GeneralError) -> Unit)? = null), который является наследником Consumer<Throwable> rxJava и хендлит ошибку.

Есть GeneralErrorFabric, со статическим методом error(throwable: Throwable): GeneralError который принимает на себя Throwable, парсит ошибку и превращает её в стандартную для проекта GeneralError (наследник Throwable).

И сам GeneralError

Я поместил их в один файл, т.к. в общем каждый класс занимает не более 10-40 строк кода и сам файл вышел в 80 строк c учётом импортов, ведь если верить https://kotlinlang.org/docs/reference/coding-conventions.html#source-file-organization то так делать можно (ведь они связаны по себе логикой и + достаточно небольшие классы).

Но будучи единственным android\kotlin разрабом мой код глянули ios'ники, чтобы и самим понимать как андроид приложение работает, так и в целом что бы говнокода по минимум было и им жутко не понравилось что это всё в одном файле живёт и что это делать так не надо. Вопрос: действительно ли стоит разбить это на файлы или просто в iOS другой мир которым и не привычно такое

Dispatchers.setMain(Dispatchers.Unconfined)

https://www.youtube.com/watch?v=KMb0Fs8rCRs
Где-то с 13 минуты то что тебе нужно, видео по андроиду но суть общая

С точки зрения официальной конвенции оба варианта вполне приемлемы.
Видимо стоит сделать так, чтобы команде было проще понимать код.

Да, действительно важный аргумент) Про команду я так и не подумал)

Ну там на самом деле не про понятливость было, а про очередное перетягивание одеяла на себя. В таком случае можно попробовать с ними просто поговорить почему они считают, что это неправильно. Полностью везде уступать им тоже не есть хорошо : )

fun f(): () -> Unit {
    return { println("f") }
}

fun main() {
    f() // должно написать предупреждение, что результат вызова f не был использован
}

Вроде есть, но она опциональная

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

Он скорей всего для всех функций, а не для конкретной

https://youtrack.jetbrains.com/issue/KT-14720
😁

Осталось только до 1.3.70 дожить