Asynchronous Programming in Android (Part 2)
In the previous post we learnt about the necessity of asynchronous programming in android and how worker threads help us to complete tasks concurrently.We also learnt how they process each jobs and pass it back to the main thread by callbacks.
As I promised earlier I will discuss some alternatives to these callback by which the worker thread can communicate the result back to the main thread.Before we proceed further lets recall the drawbacks of callback mechanism:
- They add more complication to the code and hence reduces the readability.
- Inability to return a value which is very important for exception handling.Problem arises when there is an exception and there is no means for the main thread to know about it.Though there exist a solution but its implementation is a developer’s worst nightmare .
Reactive extensions in android
The most significant issue of a callback-based approach is passing the data from one function to another. This results in nested callbacks, which are tough to read and maintain.Reactive extensions, or Rx, are built upon the idea of having asynchronous operations wrapped up in streams of events pretty much like queues.Rx incorporates the observer pattern into helpful constructs. Furthermore, there are a large number of operators that extend the behavior of observable streams, allowing for clean and expressive data processing. You can subscribe to a stream of events, map, filter, reduce and combine the events in numerous ways, as well as handle errors in the entire chain of operations, using a single lambda function.
The previous example of loading, uploading and resizing an image, using Rx, can be represented as:
Here we have just one lambda function and couple of operators.The loadImage function loads the image and passes it to another function creating new streams of data.The new stream so formed sends events in form of resizedImage which gets passed to uploadImage().Additionally, doOnSubscribe() takes an action that the stream executes whenever you subscribe to it. There are also functions like doOnSuccess and doOnError, which propagate their respective events.
Reactive extensions do provide cleaner code than writing humongous nested callbacks but they come with a price ie the learning curve is pretty steep here.With dozens and dozens of operators , streams and intervention for switching the threads, it gets pretty confusing even for senior developers to apply the right operator at the right place.
In order to incorporate Rx in your code there are number of additional concepts one has to learn for eg observer pattern , streams , reactive programming and thread scheduling .Now once you have learnt all of these concepts you will have to make lot more changes to the existing codebase in order to have Rx incorporated which again won’t align well with your existing design pattern.Speaking of which there is not any particular design pattern for Rx ,meaning each developer will incorporate Rx in his/her own way.This reminds me of the old days when android didn’t have defined design pattern and things used to get pretty messy due to it.Thanks to Google for coming out with amazing architectural components fitting in well with a uniform design pattern.
What’s next?
In the next post we will explore if there is a better or simpler way to deal with asynchronicity in android.Till then hang tight and happy coding !
