Repository navigation
@SerialBackground : serial execution in background #309
Description
The @Background is nice for executing methods in a background thread. It uses a cached thread pool for this purpose.
If you call the same method multiple times in a raw, they are executed in parallel, and you have no guarantee on the execution order. For this kind of purpose, we need a way to execute tasks in background serially.
One way to fix this for now is to call com.googlecode.androidannotations.api.BackgroundExecutor.setExecutor(Executor) and set an executor with only one thread, but this means all background operations in the app will execute on this very same thread, which isn't good.
Another solution would be to create a new @SerialBackground or an annotation parameter to the @Background annotation to use a serial behavior.
The implementation should use a HandlerThread and a dedicated Handler.
Of course, we need a way to identify methods that will execute in the same HandlerThread.
We have different solutions here :
- Use one handler thread for each class instance. This is the most simple solution, but the less flexible. This would allow creation a "Store" class and ensure that all background calls on the instance of the class are executed serially
- Identify the targeted handler by a String name and store a static cache of "name" =>
Handler. This would mean the Threads are not going to be GCed. A usage example :
@EBean
public class MyClass {
@Background(serial="MyThreadName")
public void doStuffAsync() {
}
@Background(serial="MyThreadName")
public void doStuffAsync2() {
}
}The main component would look like this :
public class SerialBackgroundExecutor {
private static Map<String, Handler> handlersByName = new HashMap<String, Handler>();
public static synchronized void execute(String name, Runnable runnable) {
Handler handler = handlersByName.get(name);
if (handler == null) {
HandlerThread thread = new HandlerThread(name);
thread.start();
handler = new Handler(thread.getLooper());
handlersByName.put(name, handler);
}
handler.post(runnable);
}
}Feedback / input is quite welcome !
Activity
pyricau commentedon Sep 1, 2012
Also notice the second solution doesn't allow a "one handler thread per instance" approach. I don't know whether this is good or bad :) .
pyricau commentedon Oct 25, 2012
We could use soft references for the handler cache to fix that.
naixx commentedon Nov 9, 2012
What about
Executors.newSingleThreadExecutor()?pyricau commentedon Nov 10, 2012
You're right, it's probably even better then using Handlers.
But still, we'd need to maintain a cache of string => single thread executor.
calexo commentedon Nov 11, 2012
Really interested in that feature !!
Just had the problem yesterday, and wondered how to solve it !
naixx commentedon Nov 11, 2012
Hi @calexo!
For now you can try the following code
So, ALL your background tasks will be serial, thats can be a bit inconvenient.
calexo commentedon Nov 11, 2012
In my case, serialising all my Background thread isn't a problem.
So I tried BackgroundExecutor and it works !
But still watching for an AA solution ;-)
Thanks a lot !
naixx commentedon Nov 11, 2012
@pyricau actually,
Executors.newSingleThreadScheduledExecutorseems to be better solution. So that we can havedelayandserialparameters. What do you think?Serial execution in background feature
Serial execution in background feature
Serial execution in background feature
yDelouis commentedon Jun 19, 2013
This should be documented in the wiki and closed.
DayS commentedon Jun 20, 2013
Wiki updated