michaelsims
10/22/2017, 5:31 PMmainThreadScheduler.executeOnThread(Runnable {
result.errorResult.let {
if (it == null) {
taskCallback.onSuccess(result.successResult)
} else {
taskCallback.onFailure(it)
}
}
})
alex.krupa
10/22/2017, 9:23 PMmainThreadScheduler.executeOnThread(Runnable {
result.errorResult
?.let { taskCallback.onFailure(it) }
?: taskCallback.onSuccess(result.successResult)
})
geatmo
10/23/2017, 7:03 AMlet
, as let
might return null
, if its last expression is null
.. so if taskCallback.onFailure(it)
would return null
for whatever reason, it would still call taskCallback.onSuccess(result.successResult)
in this caseif
here.. using let
is unnecessary for this and I think a regular if
is more idiomatic imho..Marc Knaup
10/23/2017, 9:25 AM?.also
instead of ?.let
so it won't matter if the failure handler returns null
.michaelsims
10/23/2017, 2:39 PMlet
.geatmo
10/24/2017, 8:07 AMlet
, yet, but in general I feel that something like if (variable != null) { doThis() } else { doThat() }
is for the most part better be left as a regular if else
and using let
would only end up being forced and confusingnull
I do use let
michaelsims
10/24/2017, 2:38 PMgeatmo
10/24/2017, 2:41 PMmichaelsims
10/24/2017, 2:42 PMgeatmo
10/24/2017, 3:27 PMlet
seems reasonable, although you could also just introduce a new val
variable putting the value into.. as I said just depends on personal preference