Inspired by the ideas of #309, I propose an alternative implementation for providing a serialized execution of background tasks.
The purpose is to add an optional serial attribute to
so that calls to
It is still compatible with the
executes the task in background after at least 2 seconds and after the previous task requested with
Of course, if two methods use a different
Please don't hesitate if you have any questions or feedbacks.
The text was updated successfully, but these errors were encountered:
A ScheduledExecutorService *is* an Executor, so we can use the same to avoids to create too many threads. The execute(runnable) method becomes a particular case of execute(runnable, delay), with delay=0. As the user can change the executor, delayed executions are not supported if the given executor does not support scheduling. This unification paves the way for adding serial execution feature.
Adds an optional serial attribute to @background: @background(serial="some_id") This idea comes from androidannotations#309: androidannotations#309 The principle of this implementation is to keep a separate queue for each serial identifier, and to give each task to the (unique) executor only after the previous task with the same serial identifier (if any) has completed execution. It guarantees that all tasks with the same serial identifier will be called in the order, one at a time (but not necessarily on the same thread). It is still compatible with the delay attribute. For example: @background(serial="some_id", delay=2000) executes the task in background after at least 2 seconds *and* after the previous task requested with serial="some_id" (if any) have completed execution.
Thank you for helping AndroidAnnotations.
To me, this PR introduce a lot of complexity (Semaphore, Task scheduling, synchronized blocks, etc...) and the purpose of AA is to make the use of Android API more easy. I'm not sure this feature will help developers to increase the readability of their source code and so to increase the quality of their apps.
You have added a test and this is really important in AA, however i'm not sure that only one test is enough to make sure all the things are going in the right way.
For now, i'm thinking that we should not provide such feature because AA cannot provide a solution for all the needs around threading. In fact, AA provide a simple solution for simple needs. If developers need specific features as serial threading, they can simply implement their own solution.
Finally i'm also sure that this kind of features could be provided by a separate open source project ;)
@mathieuboniface He used semaphore and synchronized blocks only for tests, it sounds good to me, though it might need some more tests to cover at least all the nominal usecases. (using different
This feature is a good one IMO, and I think it's pretty straighforward to explain in the wiki (moreover
Thank you for your review.
I will consider your individual comments, but first I would like to make a precision and a general comment.
Pull requests dependencies
I proposed two features, serial background (this one) and Cancel background tasks. They are dependent: I wrote the second over the first. As you can see, the first commits of the latter are the one of the former (I generalized the tasks management for both feature to share a large part the implementation).
I agree this can be confusing, but I don't see a better way to propose two different features with dependencies in the implementation, especially once the first has already been submitted.
Thus, this pull request in "included" in the other. Some of your comments do still apply to the new implementation, but some don't apply anymore. I will make the changes you request over the last commit.
As @JoanZapata pointed out, the concurrency tools are used essentially in functional tests.
The main code contains only mutex (
From a AA user point of view, my pull requests only adds two optional arguments to
It does not even make the generated code more complex: it just calls
There are more tests for interaction between serial and cancellation features.
If you think of other cases to test, do not hesitate.
In my opinion, serializing background tasks is not a marginal need: every time a
If a user don't use AA, then they will always use
That's why I think these features have their place in AA (whatever the implementation is).
Sorry for coming late into the party. I haven't read the code yet, because when I tried, I realized that you already took some feedback into account, fixed it in specific commits, but didn't update the branch this pull request relies on. That's the way PRs are supposed to work : once you get feedback, you add commits directly to the branch that the pull request is linked to. Then, GitHub automatically closes comments that are one lines that have been modified by a new commit.
But as explained here, this is because I did two different pull requests for two different features, with a dependent implementation.
I first did the "serial" feature (this PR), then for implementing task cancellation I improved the implementation, which now works both for serial background and task cancellation. Thus, it would not be pertinent to fix the "old" implementation of serial (this pull request) and then merge into the new (with conflicts), but directly fix the "new" one (=old+changes) instead.
In theory, this one should be forgotten: the other contains both.