-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Optionally ignore @UIThread call when @EFragment is detached from Activity? #875
Comments
Actually #823 proposed the same, but it was rejected. |
I read his actually before posting this. This is slightly different in that I'm not proposing making it the default behavior of |
Yes, you are right. |
Yeah, I prefer this solution as the developer still have the choice to handle theses cases as he want. |
I tought about the API, and bringed up a version which uses a parameter in the |
I think we could use this annotation even on methods which are not annotated with |
I think you may be right. I'll look at doing another pull request then let the authors decide which, if any, they would like to merge. |
@yDelouis > Good idea 👍 |
This is an extremely good idea!
in order to avoid the problem when switching really fast through fragments. An annotation like that makes total sense. |
Merged. Thanks to @yDelouis and @vincentjames501 for this |
When using
@Background
in conjunction with@UIThread
annotations on an@EFragment
, it's possible that many developers don't want to run the method annotated with the@UIThread
annotation if the Fragment is no longer attached to the activity. I think it would be great to add an annotation (something like@IgnoredWhenDetached
) with the following rules:@UIThread
annotation@EFragment
classes@UIThread
method call in an if block like soor
Here is a simple example and in my application I have dozens of things similar to this
This essentially prevents the two
@UIThread
methods from getting a NPE if the Fragment were to have been destroyed at any point during the execution of the@Background
method. While I realize this is something that can be easily guarded against by a simple null check, it makes the code much cleaner and is a very common use case in conjunction with Fragments. I would be more than happy to submit a pull request pending thoughts/comments about this. This could also be useful in conjunction with@Background
on an@EFragment
as well, but not a very common use case.Vince
The text was updated successfully, but these errors were encountered: