Callback Hell is very scary term. It intimidates inexperienced developers, who desperately try to avoid this situation in their code, but fail quite often. On the other end of the spectrum, Callback Hell gives conference speakers and frameworks designers lots of material to discuss and work with.

In this post I’ll explain what Callback Hell is and how to fix it in your code.

Callback Hell

In general, you can get “callback hell” when you compose multiple asynchronous flows that use so-called callback methods to pass execution results back to their callers. Such a composition can be difficult to understand, thus hurting the maintainability of your codebase.

For the sake of demonstration, suppose that you need to fetch data from internet, perform some time-consuming processing on it and then store the results into local database. Furthermore, let’s assume that you already have three standalone components that take care of each of the aforementioned steps.

In this situation, you could implement the required flow in the following way:

public void executeFlow(final FlowCallback flowCallback) {
    mNetworkEndpoint.executeRequest(networkResult -> {
            if (!networkResult.isSuccess()) {
                flowCallback.onFlowCompleted(FlowCompletionResult.NETWORK_ERROR);
                return;
            }
            mDataProcessor.processData(networkResult, dataProcessingResult -> {
                    if (!dataProcessingResult.isSuccess()) {
                        flowCallback.onFlowCompleted(FlowCompletionResult.PROCESSING_FAILED);
                        return;
                    }
                    mDao.storeData(dataProcessingResult, () -> {
                            flowCallback.onFlowCompleted(FlowCompletionResult.SUCCESS)
                                });
                });
        });
}

This code is quite difficult to read and reason about. Furthermore, maintenance and future additions to this beast are likely to be risky. Just imagine that one day you’ll need to add additional three steps to this flow. That’s your classical Callback Hell.

By the way, the above example is simple and small. Callback Hell can get much more problematic than that. Click this link to see really nasty real-world callback hell (thanks to Gabor Varadi for the link).

In my experience, even if code with Callback Hell works initially, it’ll come to bite you in the ass in the long term. Therefore, you need to do something about that.

Callback Hell Root Cause

If you think about it, it’s very simple to call a method and return the result of its execution synchronously. If you do that, there is no need for callbacks and no risk of descending into callback hell. Why would anyone even use callbacks then?

Well, the problem arises once you need to execute time-consuming tasks in GUI frameworks.

For example, if you’d write Java backend app, your life would be relatively simple (at least in the context of callbacks) because backend frameworks execute each server request on a dedicated thread. Therefore, you’d be able to execute all the operations synchronously and then simply return the result to the caller over HTTP. No need for callbacks at all.

However, if you’d write Android app, it wouldn’t be that simple anymore.

In Android, all the code related to GUI should execute on a special UI thread. This thread shouldn’t be blocked for any reason. Therefore, you can’t execute network requests and other time-consuming tasks on UI thread and need to offload them to so-called background threads. Once you do that, you need to use callbacks to deliver results back to UI thread.

So, callbacks are necessary evil in GUI frameworks required to support concurrency. Their usage allows for asynchronous notifications upon completion of concurrent flows. Alright, but how do we get from here to callback hell?

Callback hell is just a composition of several tasks that use asynchronous notifications. Please note that these tasks can be concurrent, but they don’t have to. The emergence of callback hell isn’t really predicated on the threading implementation details of the tasks, just on the asynchronous nature of their API.

Callback Hell Resolution

So, callbacks are inevitable in one form or another if we want to have asynchronous notifications. That’s true, but it doesn’t mean that callback hell is inevitable.

In the above example, the method executeFlow() must receive callback as an argument because we want to be able to invoke it on UI thread and be notified about the results later. But do we really need to call its internal collaborators on UI thread? The answer is no!

Let’s assume that all objects which constitute this flow handle multithreading internally. In other words, they offload execution to background threads and return to UI thread before invoking their callbacks. In total, during this flow, there will be three transitions from UI thread to some background thread and another three transitions back to UI thread. Feels a bit too much, don’t you think?

Instead, let’s reduce this flow to just one offload to a background thread and one return to UI thread:

public void executeFlow(final FlowCallback flowCallback) {
    mBackgroundThreadPoster.post(() -> executeFlowSync(flowCallback));
}

@WorkerThread
private void executeFlowSync(FlowCallback flowCallback) {
    NetworkResult networkResult = mNetworkEndpoint.executeRequestSync();
    if (!networkResult.isSuccess()) {
        notifyFlowCompleted(flowCallback, FlowCompletionResult.NETWORK_ERROR);
        return;
    }
    ProcessingResult processingResult = mDataProcessor.processDataSync(networkResult);
    if (!processingResult.isSuccess()) {
        notifyFlowCompleted(flowCallback, FlowCompletionResult.PROCESSING_FAILED);
        return;
    }
    mDao.storeDataSync(processingResult);
    notifyFlowCompleted(flowCallback, FlowCompletionResult.SUCCESS);
}

private void notifyFlowCompleted(final FlowCallback flowCallback, final FlowCompletionResult result) {
    mUiThreadPoster.post(() -> flowCallback.onFlowCompleted(result));
}

I use ThreadPoster library for concurrency in the above implementation, but you could use a bare Thread class and UI Handler in exactly the same manner.

The first thing you might notice is that the code became longer. I don’t mind that. In fact, I could spare several lines of code if I wouldn’t extract additional methods, but I’m always willing to write more code to get better design and readability. In this case, the flow itself is encapsulated in executeFlowSync() method, which contains synchronous, step by step, simple definition of what needs to be done. Two other methods handle concurrency.

The upsides of this approach should become clear if you imagine that one day you’ll need to add three more steps to this flow. With this implementation, it would be simple task confined to executeFlowSync() method and there would be no callbacks involved at all. In addition, since the collaborator objects are invoked synchronously, they don’t need to handle multithreading and support asynchronous notifications, so their internal implementation can be simplified a lot.

Eventually, you’ll realize that this entire flow with all its dependencies can be encapsulated in a standalone object. Then the clients won’t know anything about its implementation details and it’ll be ready for future reuse. That’s basically the idea behind “use case” classes (also known as “interactors”) which are part of Clean Architecture school of thought.

Resolving Callback Hell Using Frameworks

Many developers “smuggle frameworks” into the picture as part of callback hell discussion. The argument goes like this: “Framework X fixes callback hell with zero effort (or is immune to callback hell to begin with), so just use it and you’re done”. With all due respect, I, personally, think that if you don’t address callback hell with better design and encapsulation, then your solution won’t be optimal.

RxJava, for example, allows you to convert an ugly chain of callbacks into a bit less ugly chain of operators. This is just a band aid. The resulting code might be shorter and less indented, but hardly any better. Long chains of Rx operators without proper abstractions are almost as harmful to your project as long chains of nested callbacks.

Similar argument can be made about Kotlin Coroutines. Coroutines-based code looks quasi-sequential, so it feels like the silver bullet solution to callback hell. In some sense, it is. However, that’s still an asynchronous code and the nuances of Coroutines framework itself add much additional complexity.

Therefore, while frameworks can mitigate the problem of callback hell to some degree, they aren’t necessary and they aren’t sufficient to address that problem properly on their own.

Conclusion

Callback Hell is a very popular topic among web-frontend developers, but it has a strong grip in Android community as well. It’s a real problem that can cause a real harm to maintainability of your codebase.

Luckily, preventing, or fixing callback hell is possible. The solution I use basically amounts to establishing proper multithreading boundaries in the app and avoiding unneeded asynchronous notifications. It’s not simple, but not a rocket science either. For example, I use this technique when I need to compose “use case” classes as described in this article.

While Callback Hell is quite often used to market specific frameworks and language features, these aren’t necessary and aren’t sufficient to address this problem on their own. Therefore, I recommend paying attention to the concepts discussed in this article even if you use the latest and the greatest framework out there.

As usual, thanks for reading. Leave your comments and questions below.