> Kotlin syntax I am reading sample Clean Architecture code of Fernando Cejas. He implement as t...

# android

[Breaker ACT]

Kotlin syntax

I am reading sample Clean Architecture code of Fernando Cejas. He implement as the images, how you think about this approach ?
The pros: We can invoke the interface/abstract class which has been injected like a function call
Ref

[Adam Powell]

that blog post refers to it being 2018, which would line up with potentially being written pre-structured concurrency. A lot has changed since then; I would look for some more recent material to reference

[Adam Powell]

as it stands that code contains a number of concurrency and threading bugs, has two ways errors can escape from run implementations, one of which will crash the app probably unexpectedly, misuses the IO dispatcher and its associated thread pool...

[Breaker ACT]

@Adam Powell Can you please to give me the newer reference ?

[Adam Powell]

I don't have any favorite links on good examples of "clean architecture" in particular on hand, no. If that's a pattern you would like to learn more about I would search around the web and specifically look for material written in the last year or so

[Breaker ACT]

@Adam Powell Thank you.
In his sample I really love the Either class, maybe it come from Arrow.kt. It save me from a lot of boilerplate code. How you think about it ? Any improvement can be

[Adam Powell]

I don't think that generic Either types work very well in Kotlin for application code despite the functional programming community's enthusiasm for them. 🙂 You'll note Kotlin has its own Result type of this form, but it's primarily used for infrastructure code that has to manage things like resuming coroutine continuations with either a returned result or a thrown exception. Thrown exceptions still feature heavily there.

[Adam Powell]

Domain-specific result types can be very useful, but once you generalize it to something like Either here, you end up reinventing a lot of language features for error handling and propagation. "railway-oriented programming" is the term to search for this

[Adam Powell]

and it's the source of some of the issues I mentioned above - if an exception is thrown by either run or onResult in the images above, where does that exception go? what opportunities are afforded to the developer to handle them? The use of an Either type implies a single error propagation path that is not thrown exceptions, but meeting that expectation involves yet more consideration and boilerplate that is not present in this example

[Adam Powell]

Kotlin's structured concurrency has some very good answers to these questions but this code as written works very hard to defeat almost all of them 🙂

[Breaker ACT]

@Adam Powell Thank for your sharing, I will research more about your point.

[Adam Powell]

https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07 is a good read on the error handling topic in particular and gives an example of a domain-specific result type

[Breaker ACT]

@Adam Powell Actually, I am following this implementation way.
For example, we divide whole app into small modules, every modules have their own result wrapper class like:

sealed class AuthResource<out T> {

    data class Failure(val error: AuthError) : AuthResource<Nothing>()

    data class Success<T>(val result: T) : AuthResource<T>()
}

But when we need to chaining multiple usecase (interactor) call we have to check the type of result so much.
When using Either, we can use the operator flatMap to call the next usecase if previous is success result.
Any idea for my wonder ?

[Breaker ACT]

For example:
val result1 = authUseCase1.execute()
if(result1 is AuthResource.Success) {
val result2 = someUseCase.execute()
if(result2 is Result.Success) {
.. . . . . .
}
}

[Adam Powell]

please stop with the @-mentions, I'll see thread updates. 🙂

[Breaker ACT]

Got it. Sorry for that disturb.

[Adam Powell]

and yes, you're seeing why the style of result types can scale very poorly. If the design of these functions threw an exception instead when they could not satisfy their contract, then a higher-level exception handler like those described in the blog post in the I/O section makes the code quite a bit cleaner

[Breaker ACT]

That is exact thing i’m looking for. Can you please to give me any reference? which post I/O you’are mentioning ?

[Adam Powell]

the blog post I linked above

[Breaker ACT]

I see. Thank you for your supporting 🙏