Repository navigation
Optionally ignore @UIThread call when @EFragment is detached from Activity? #875
Description
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:
- Must also have the
@UIThreadannotation - Can only be used in conjunction with
@EFragmentclasses - Simply wraps the
@UIThreadmethod call in an if block like so
if(isAdded()) {
//executable code
}or
if(getActivity() != null) {
//executable code
}Here is a simple example and in my application I have dozens of things similar to this
@EFragment
public class LoaderFragment extends Fragment {
@Background
void longTask() {
try {
updateProgress(0);
Thread.sleep(1000);
updateProgress(50);
Thread.sleep(1000);
updateProgress(100);
} catch (InterruptedException e) {
killActivity()
}
}
@IgnoredWhenDetached
@UiThread
void updateProgress(int progress) {
getActivity().setProgress(progress);
}
@IgnoredWhenDetached
@UiThread
void killActivity(int progress) {
getActivity().finish();
}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
Activity
WonderCsabo commentedon Jan 11, 2014
Actually #823 proposed the same, but it was rejected.
vincentjames501 commentedon Jan 11, 2014
I read his actually before posting this. This is slightly different in that I'm not proposing making it the default behavior of
@UIThreadfor@EFragmentclasses.WonderCsabo commentedon Jan 11, 2014
Yes, you are right.
DayS commentedon Jan 11, 2014
Yeah, I prefer this solution as the developer still have the choice to handle theses cases as he want.
This may be in 3.1 :)
WonderCsabo commentedon Jan 13, 2014
I tought about the API, and bringed up a version which uses a parameter in the
@UiThreadand not a new annotation. But i changed my mind since this feature is only forFragments,@UiThreadAPI should not be affected.I think you can start to implement this if you want. :)
yDelouis commentedon Jan 13, 2014
I think we could use this annotation even on methods which are not annotated with
@UIThreador@Background.vincentjames501 commentedon Jan 13, 2014
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.
DayS commentedon Jan 13, 2014
@yDelouis > Good idea 👍
toshe commentedon May 17, 2014
This is an extremely good idea!
I'm currently using
in order to avoid the problem when switching really fast through fragments. An annotation like that makes total sense.
DayS commentedon Jun 8, 2014
Merged. Thanks to @yDelouis and @vincentjames501 for this