mapbox
Move ReplayRouteMapper interaction to a worker thread
The ReplayRouteMapper can take a significant amount of time parsing geometries when leg switches or when the simulation is started, we should look into options of moving the processing out of the main thread.
/cc @kmadsen @Guardiola31337
I don't want to introduce threading into the *Mapper classes. This is to keep mapper classes simple for what they are testings. Convert one thing to another. Threading also introduces race conditions.
I am in favor of building a service class on top of the ReplayRouteMapper though, that handles the tasks on background threads. At this point, it is up to the developer to decide this. It's not a lot of work if your app is already set up with coroutines or Rx.
For example, ReplayProgressObserver is a service class. The internals there should be done on a background thread, because developers are not able to control the threading there.
That makes sense to me :+1: If we don't want to invest in managing the threading internally right away, we can simply update the documentation and examples to make developers aware of the costs of the mappers and showcase the async usage.
