Managing long running task in React Native

In React Native network request is normally done with non-blocking method like fetch(). On receiving result redux-thunk middleware can be used to dispatch the new state.

Now there is a question: how to make our own non-blocking method for performing lengthy computation. This can be done using 3rd-party native extensions that introduce threading or WebWorkers to react native, or writing our own extension. There is also a workaround with creating a WebView and moving the long running function there.

There is a lighter solution, that would block the JS thread, but it allows for showing the progress indicator. Assume I want to perform an action that takes a few seconds, but first shows a progress indicator.

This action would block JS thread:

export const getData = () => {
   for (i = 0; i < 5000; i++) {
       console.log(i)
   }
   return { type: DATA_READY } 
}

To show the progress let us switch from 'return' to redux-thunk 'dispatch', and add additional state change before the computation. The flag 'loading' would be used to show progress bar in view.

export const getData = () => {
  return (dispatch) => {
    dispatch({type: DATA_CALCULATION loading: true})

    for (i = 0; i < 5000; i++) {
       console.log(i)
    }

    dispatch( { type: DATA_READY loading: false })
  }
}

The progress would not be shown despite the new state would have 'loading:true' set before computation. This happens because getData() action blocks for quite some time after the first dispatch(). This prevent the view from receiving its render() call. To make the view render before the blocking code we should move the lengthy cycle into the requestAnimationFrame() callback:

export const getData = () => {
  return (dispatch) => {
    dispatch({type: DATA_CALCULATION loading: true})

    requestAnimationFrame(() => {

       for (i = 0; i < 5000; i++) {
          console.log(i)
       }

       dispatch( { type: DATA_READY loading: false })
   })
  }
}

The requestAnimationFrame() callback is invoked before next repaint, and view now gets its render() call before the 'for' loop being launched. Progress indicator is shown and then it gets updated on main (UI) thread, while JS thread would be blocked.

Handling exceptions thrown from ActivityThread in Android

Sometimes it is desired to prevent the default exception handler from terminating application. This may be done via setting custom default uncaught exception handler.

What happens if the caught exception is thrown from ActivityThread? See Android/Sdk/sources/android-26/android/app/ActivityThread.java for the source. When exception is thrown from ActivityThread the Looper.loop() cycle invoked from ActivityThread.main() method terminates. As the exception is caught by custom default exception handler, it does not instruct application to finish. However, application becomes frozen. Main looper no longer processes new messages.

To make application run again, the main looper needs to be revived. This can be done inside the custom exception handler:

    private void setOnErrorFailedExceptionHandler() {
        android.os.Handler handler = new android.os.Handler(Looper.getMainLooper());
        Thread.UncaughtExceptionHandler uncaughtExceptionHandler =
                                        Thread.getDefaultUncaughtExceptionHandler();
        Thread.setDefaultUncaughtExceptionHandler((t, e) -> {

            if (e instanceof AndroidRuntimeException 
                        /*&& e is a specific exception that needs treatment*/) {
                android.util.Log.e("error", "DefaultUncaughtExceptionHandler", e);
                Looper.loop() // Revive main looper 
            } else if (uncaughtExceptionHandler != null) {
                // All other exceptions should be treated by default
                uncaughtExceptionHandler.uncaughtException(t, e); 
            }
        });
    }

Some edge cases may be solved with this trick. For example, take the introduction of new exception in Android O "android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()". The stacktrace for this exception shows that is is thrown from ActivityThread:

"android.app.ActivityThread$H.handleMessage(ActivityThread.java:1775)"
"android.os.Handler.dispatchMessage(Handler.java:105)"
"android.os.Looper.loop(Looper.java:164)"
"android.app.ActivityThread.main(ActivityThread.java:6541)"
"java.lang.reflect.Method.invoke(Native Method)"
"com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)"
"com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)"

The android.app.RemoteServiceException is a private exception, that subclasses AndroidRuntimeException.

This exception is meant to terminate application, so that the developers should follow the new foreground service rules. If time span between the startForegroundService() and setForegorund() call in Service.onCreate() is longer than ANR period, then this exception is thrown. It was not designed to be caught. There are a few catches though, when terminating application with a crash is undesired, given that "startForegroundService() -> startForeground()" rule is already implemented.

1. During debug sessions this exception fires quite often, because of slower emulator - or just the breakpoints being hit.
2. When released, the actual user device may lag in the very unfortunate moment between those calls, and app will be hit with the crash.

Especially in the second case it would be much better to retry the service start, or opt it to be started later, instead of crashing app altogether. Catching such exception and reviving main loop afterwards is possible with this approach.