Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Merge @UiThread and @UiThreadDelayed? #97

Closed
pyricau opened this Issue Feb 3, 2012 · 7 comments

Comments

Projects
None yet
4 participants
Contributor

pyricau commented Feb 3, 2012

I think maybe we should merge @UiThread and @UiThreadDelayed, by adding a value() paramater to the @UiThread annotation that would be the delay :

@UiThread(3000)
void delayed() {

}

@UiThread // Equivalent to @UiThread(0)
void onUiThread() {

}
Contributor

pyricau commented Feb 3, 2012

Of course we should probably start by deprecating @UiThreadDelayed in 2.5, and removing it in next release.

Contributor

mathieuboniface commented Feb 3, 2012

I vote for it !

Contributor

JoanZapata commented Feb 7, 2012

I don't think using the value is a good idea, as @UiThread(3000) isn't self-explanatory.
Having @UiThread(delay=3000) would be more appropriate IMO.

Although, I'm not sure about the actual usage of it, but this feature could be easily applied to any method.
What about this?

@UIThread
@Delay(3000)

With @Delay applicable to any method.

Contributor

pyricau commented Feb 7, 2012

Hum, I'm not sure I really like this idea. The thing with the "delay" here is to use it on the UI thread. If we created a specific @Delay annotation, the method would need to be executed on another thread. I don't like the idea of spawning new threads when it's not clear you're doing it.

Contributor

pyricau commented Feb 7, 2012

Otherwise, you're right that @UiThread(delay=3000) or even @UiThread(delayInMs=3000) would be clearer, although it adds a bit of clutter.

Any other opinion ?

Contributor

JoanZapata commented Feb 7, 2012

I agree about @Delay.

I vote @uithread(delay=3000)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment