I have a fragment (F1) with a public method like this
public void asd() {
if (getActivity() == null) {
Log.d("yes","it is null");
}
}
and yes when I call it (from the Activity), it it is null...
FragmentTransaction transaction1 = getSupportFragmentManager().beginTransaction();
F1 f1 = new F1();
transaction1.replace(R.id.upperPart, f1);
transaction1.commit();
f1.asd();
It must be something that I am doing very wrong, but I don't know what that is
The other answers that suggest keeping a reference to the activity in onAttach are just suggesting a bandaid to the real problem. When getActivity returns null it means that the Fragment is not attached to the Activity. Most commonly this happens when the Activity has gone away due to rotation or the Activity being finished, but the Fragment has some kind of callback listener. When the listener gets called if you need to do something with the Activity but the Activity is gone there isn't much you can do. In your code you should just check
getActivity() != null
and if it's not there then don't do anything. If you keep a reference to the Activity that is gone you are preventing the Activity from being garbage collected. Any UI things you might try to do won't be seen by the user. I can imagine some situations where in the callback listener you might want to have a Context for something non-UI related, in those cases it probably makes more sense to get the Application context. Note that the only reason that theonAttach
trick isn't a big memory leak is because normally after the callback listener executes it won't be needed anymore and can be garbage collected along with the Fragment, all its View's and the Activity context. If yousetRetainInstance(true)
there is a bigger chance of a memory leak because the Activity field will also be retained but after rotation that could be the previous Activity not the current one.The best to get rid of this is to keep activity reference when onAttach is called and use the activity reference wherever needed, for e.g.
This happened when you call
getActivity()
in another thread that finished after the fragment has been removed. The typical case is callinggetActivity()
(ex. for aToast
) when an HTTP request finished (inonResponse
for example).To avoid this, you can define a field name
mActivity
and use it instead ofgetActivity()
. This field can be initialized in onAttach() method of Fragment as following:In my projects, I usually define a base class for all of my Fragments with this feature:
Happy coding,
PJL is right. I have used his suggestion and this is what i have done:
defined global variables for fragment:
private final Object attachingActivityLock = new Object();
private boolean syncVariable = false;
implemented
3 . I wrapped up my function, where I need to call getActivity(), in thread, because if it would run on main thread, i would block the thread with the step 4. and onAttach() would never be called.
4 . in my function where I need to call getActivity(), I use this (before the call getActivity())
If you have some UI updates, remember to run them on UI thread. I need to update ImgeView so I did:
The order in which the callbacks are called after commit():
I needed to do some work that involved some Views, so onAttach() didn't work for me; it crashed. So I moved part of my code that was setting some params inside a method called right after commit() (1.), then the other part of the code that handled view inside onCreateView() (3.).
Since Android API level 23, onAttach(Activity activity) has been deprecated. You need to use onAttach(Context context). http://developer.android.com/reference/android/app/Fragment.html#onAttach(android.app.Activity)
Activity is a context so if you can simply check the context is an Activity and cast it if necessary.