Skip to content
This repository was archived by the owner on Feb 26, 2023. It is now read-only.

Conversation

@yDelouis
Copy link
Contributor

@yDelouis yDelouis commented Mar 4, 2013

Hi,

This commit is a solution for the issue #332.

Because the class Executor does not have a method executeDelayed, I use a Handler to postDelayed the call to the method execute.

Comments are very welcome.

@pyricau
Copy link
Contributor

pyricau commented Mar 5, 2013

Hi,

Thank you for contributing this. However, I don't think you need to use a Handler this. The JDK already has the needed bits : http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ScheduledExecutorService.html

@yDelouis
Copy link
Contributor Author

yDelouis commented Mar 5, 2013

I didn't know about ExecutorService.
I'll change that soon.

@yDelouis
Copy link
Contributor Author

yDelouis commented Mar 9, 2013

I switched from Handler to ScheduledExcutorService.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The core pool size set to 1, which AFAIK means the maximum number of threads on this executor will always 1. As a consequence, you'll never get two delayed tasks to run concurrently. Is that on purpose ? @Background has always had a parallel behavior, if we want serial behavior which should make a clear distinction.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know which value to set here. Maybe a big one (ex: Integer.MAX_VALUE) or maybe we should create a ScheduledExecutorService each time we call executeDelayed ? Do you know the effect of a value of 0 for the core pool size ? It's not said in the java doc and it doesn't seem to rise an exception.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be a good thing to let the user defines how many threads he wants because this is typically a parameter that changes according to the needs.

Maybe with another optional parameter in the @Background annotation. If the user doesn't fill this parameter, assign a default value to 5 for the corePoolSize.

What do you think about this idea?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's a good idea as it means each @Background could be responsible of the creation of a thread pool. That could cause a performance issue, and it could be hard to understand from a developer point of view.

I would prefer to define a value. Something like that :

What do you think ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think Mathieu is right. The more so as a developper will be able to change the ScheduledExecutorService using the static method of BackgroundExecutor. Regarding the value to set, I have no idea.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@yDelouis
Copy link
Contributor Author

I changed the corePoolSize.

mathieuboniface added a commit that referenced this pull request Apr 13, 2013
@mathieuboniface mathieuboniface merged commit a1f430a into androidannotations:develop Apr 13, 2013
@mathieuboniface
Copy link
Contributor

Great work 👍

@yDelouis yDelouis deleted the 332_DelayInBackground branch April 13, 2013 15:21
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants