Я полагаю, что вы работаете не против выполнения кода, а против предупреждающих сообщений вашей IDE или только за способность этого кода компилироваться.Вероятно, вы столкнетесь с тем, что более ранние проверки для null
не обязательно позволят компилятору принимать ненулевые значения позже, потому что в то же время другой код в другом потоке мог бы выполняться и изменять значения.
Поэтому, когда вы создаете WinbackListItem, вы можете смело предполагать, что некоторые элементы не равны NULL, и все же компилятор не может быть уверен в этом, потому что он не может знать, что еще происходит в вашем файле.пространство процесса.Таким образом, компилятор требует, чтобы вы указали ему не беспокоиться о нулевых значениях (!!) или что вы проверите значения снова.Так работает Котлин.Часто это PITA, но так оно и есть.
Я играл с опубликованным кодом, просто чтобы быть уверенным, что знаю, о чем говорю.Вот код, который мне удалось выполнить:
private fun getWinbackDataItems(rewardPurpose: String) /*Single<WinbackBaseItem>*/ {
val x = repository.getRewardsList(rewardPurpose)
.filter {
it.result?.rewards != null
}.map { winback ->
winback.result?.rewards?.asSequence().filter { rewardsItem ->
rewardsItem.id != null && rewardsItem.title != null
}.toList().take(3).map {
println(it.id)
println(it.title)
WinbackListItem(it.id!!, it.title!!, false)
}.toList()
}.count()
}
Я создал несколько очень простых классов и объектов, чтобы удовлетворить этот код и позволить ему работать.Обратите внимание, что я вынул некоторые ненужные '?'нулевые проверки.Я играл с входными значениями, пока не убедился, что it.id
и it.title
никогда не могут быть null
при вызове конструктора WinbackListItem.И все же, два !!
в его параметрах или что-то еще, удостоверяющее, что они не null
, требуются, учитывая это определение WinbackListItem, которое не будет принимать null
значений параметров:
class WinbackListItem(val id: Int, val title: String, val huh: Boolean)