blockingGet() and its Story in Android

Table of content

• Actual definition of blockingGet()
• Simplification
• Usage of blockingGet() in Android
• Caution of using blockingGet()
• Issues due to use of blockingGet()
• Conclusion

Actual definition of blockingGet()

Waits in a blocking fashion until the current Single signals a success value (which is returned) or an exception (which is propagated).

Simplification

• If working with reactive programming or asynchronous code, blockingGet() could be a method provided by a specific library called RxJava or Project Reactor.
• blockingGet() or block() are used to synchronously wait for the result of an asynchronous operation.
• used in scenarios where there is a need to block the current thread and wait for the result.

Usage of blockingGet() in Android

1. Observable or Single:

   blockingGet() is typically used with an Observable or Single, which represents an asynchronous computation or stream of data.

val observable: Observable<String> = // ... some asynchronous operation

2. Blocking Execution:

   When blockingGet() is called on an observable, it blocks the current thread and waits for the observable to emit a result or complete.

try {
    val result: String = observable.blockingGet()
    // Do something with the result
} catch (e: Exception) {
    // Handle exceptions
}

3. Thread Blocking:

   blockingGet() in Android should be done with caution. Blocking the thread can lead to performance issues, especially on the main (UI) thread. It’s generally recommended to use non-blocking alternatives, such as operators like observeOn() or subscribeOn(), to perform asynchronous operations without blocking the thread.

observable
    .observeOn(AndroidSchedulers.mainThread()) // Observe on the main thread
    .subscribe { result ->
        // Handle the result on the main thread
    }

4. Exception Handling:

   The try-catch block is used to handle any exceptions that may occur during the blocking operation.

try {
    val result: String = observable.blockingGet()
    // Do something with the result
} catch (e: Exception) {
    // Handle exceptions
}

Caution of using blockingGet()

• Using blockingGet() or any other blocking operation in a background function in Android should be approached with caution. - Using blocking operations in the background can lead to performance issues, unresponsiveness, and potential application crashes.
• When working with reactive programming libraries like RxJava, it’s important to use non-blocking alternatives to maintain the responsiveness of your application.
• Instead of blocking operations, consider using operators like observeOn() or subscribeOn() to perform asynchronous operations without blocking the current thread.

Below is a code snippet to use operators like observeOn() or subscribeOn() to perform asynchronous operations without blocking the current thread.

import io.reactivex.rxjava3.core.Single
import io.reactivex.rxjava3.schedulers.Schedulers

fun performBackgroundOperation(): Single<String> {
    return Single.fromCallable {
            // Simulate a time-consuming operation
            Thread.sleep(2000)
            "Operation Result"
        }
        .subscribeOn(Schedulers.io())
        .observeOn(Schedulers.single())
}

Issues due to use of blockingGet()

1. Blocking the Thread: blockingGet() is a blocking operation that causes the current thread to wait until the result is available, can lead to unresponsiveness in the application, resulting in a poor user experience.

2. Performance Issues: Blocking operations can negatively impact the performance of the application, it might lead to decreased throughput and responsiveness.

3. Potential ANR (Application Not Responding): If blockingGet() is used on the main thread and the operation takes a significant amount of time, it could trigger the Android system’s Application Not Responding (ANR) dialog, causing the app to be terminated.

4. Limited Concurrency: Using blockingGet() restricts concurrency, as it blocks the thread until the operation completes. This might be problematic in scenarios where one wants to perform multiple concurrent operations without waiting for each to complete.

5. Difficult Debugging: Blocking operations can make debugging more challenging. Debugging tools might not behave as expected when threads are blocked.

Conclusion

In summary, it’s recommended to avoid using blocking operations like blockingGet() on critical threads, especially the main thread in Android applications. Explore alternative approaches that provide asynchronous behavior without sacrificing performance and responsiveness.