Спасибо

Сомнительная польза от такого extension. Обычный if задом наперед.

Еще можно добавить operator и будет так:

inline operator fun Boolean.invoke(code: () -> Unit) {
    if (this) code()
}

(1 == 1) { println(true)}

Я понял спасибо, проще написать как есть)

нет если у тебя идут let подобные выражения

Использую Json serialization в связке с Retrofit для маппинга моделей

При отправке запроса возвращается следующая ошибка:
kotlinx.serialization.json.internal.JsonDecodingException: Unexpected JSON token at offset 48: Expected string or non-null literal
JSON input: {
"timestamp": "2020-10-21T11:07:36",
"data": {},
"isError": false
}

Мой JsonConverterFactory:
Json {
   ignoreUnknownKeys = true
   allowSpecialFloatingPointValues = true
   isLenient = true
}.asConverterFactory(contentType)

Я так понимаю, что он ругается на то, что в значении data пустой Json объект. Свойство data у меня nullable и по дефолту принимает значение null. Все поля объекта data имеют значения по умолчанию

Как исправить эту ошибку?

Думаю сделать "data" : null

привет, курсы бесплатные, желательно с картинками.. посоветуйте.. Чтоб прямо крутые и бесплатные по Котлин

Посмотри в описании @kotlin_lang

ну такое..

Ну не смотри

Привет. Вопрос по базовому ооп, но всё же хочу узнать ваше мнение. Есть абстрактный класс, который много где юзается, и я хочу добавить несколько функций, но не изменяя его. Я создал свой абстрактный класс, унаследовался от того, чей интерфейс мне нужен и добавил нужные мне методы. Вроде бы, всё отлично. Но ведь остались абстрактные методы, которые надо определить в наследнике. Я сделал подобную запись "abstract override fun action(item: T)". Так вот хочу узнать, нормально ли это вообще делать подобную запись?

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

Это я понимаю, но всё же, система уже написана до меня. Мне же стало интересно подходит ли такой кейс. Ведь, по сути, в рамках ООП в таком решении нет ничего плохого. То есть, это нормально если я хочу унаследовать одним абстрактным классом другой

Конечно, так наследовать можно.

Спасибо за ответ :)

В котлине можете подложить реализацию другого класса используя делегирование, если этот вариант подходит

в случае абстрактного класса не подходит

И правда, прошу прощения

ну абстрактный класс редко существует в вакууме , скорей всего есть какая-то реализация