1

For Android: I have

  • a core library with some basic functions: libCore . libCore is written is Java and contains some basic functions with calculations, does not contain any Android related libraries, pure Java. It has an interface offering those functions to the outer ring
  • a library, what suses this core: libModule . libModule is written in Kotlin and is an Android library. libModule imports libCore and combines those basic calculations to more complex functions.
  • finally my Android App : myApp . myApp is an Android App written also in Kotlin, this just imports libModule and not libCore. On this level we want to hide libCore stuff and do want to see any libcore stuff here..

enter image description here

I have a battery of callbacks from libModule to myApp, which I combined in the meanwhile to some Wrapper classes. Example:

class LoginCallbackWrapper {
 internal lateinit var authenticationCallback : AuthenticationCallback
 internal lateinit var loginCallback : LoginCallback
 internal lateinit var andDozenOtherCallback: DozenOtherCallbacks

 val isAuthInitialized = fun(): Boolean{
  return ::authenticationCallback.isInitialized
 }
 //.. also for the other callbacks

}

Further I have other CallbackWrapper with combined Callbacks.

I was hopeing there is another more elegant way for these amount of callbacks? Any design pattern, another library.. I've heard something about Dagger2. So maybe with dependency injection?

NoamEpstein
  • 127
  • 10
  • I think that for any async task that is potentially long running in the background, and you have functions which seem to allow checking as to wheather any of them are currently running... you are going to have to do book keeping of those long running tasks in some way; keeping a reference and checking on state etc. Even if you wrapped these in coroutines, you would still need to keep a ref to the job to be able to do that check... feels like you might be stuck with it.. – Laurence Apr 10 '19 at 12:45
  • What's wrong with the callbacks you have? Spring provides callback hooks for all of its lifecycle events. That's generally the nature of event-driven programming. – jaco0646 Apr 10 '19 at 12:45
  • Terminology nitpicks : that's not what is usually called [callback hell](http://callbackhell.com/). I would also avoid the term clustered as it has a specific meaning in the industry (multiples instances of the same process set up to increase concurrency) – Aaron Apr 10 '19 at 12:48
  • @Aaron Hell <- amount and clustered <- combined – NoamEpstein Apr 10 '19 at 13:22
  • Those callbackWrappers you've written, they are in libModule or myApp? It may be that the abstraction work in libModule hasn't been pushed far enough and that it exposes an API that is still too low-level : I have a hard time understanding why a frontend would need to orchestrate asynchronously a dozen functions just to log an user in. – Aaron Apr 10 '19 at 15:08

0 Answers0