Develop Reference

Android Kotlin: Fragment not attached to a context

I am trying to use a TabLayout with different fragments and have started with AndroidStudio's automatically generated code for the tabbed layout. I have not changed how the placeholder fragment is created, displayed, handled etc.: The fragment is handled by a FragmentPagerAdapter, which is used by a ViewPaper, which in turn is used to setup the TabLayout.
The layout already included a FAB. Its onClick looks like this:
fab.setOnClickListener { view ->
val currentFragment: Fragment = sectionsPagerAdapter.getItem(viewPager.currentItem)
when (viewPager.currentItem) {
0 -> doSomething()
1 -> (currentFragment as PlaceholderFragment).fabOnClick()
else -> doSomethingElse()
}
}
Eventhough the above code makes sure that fabOnClick() is only called on the currently visible fragment, when I am trying to get a context using requireContext() in the PlaceholderFragment, java throws the following exception:
java.lang.IllegalStateException: Fragment PlaceholderFragment{660c58b} (08f94c5f-64b3-4a50-a1d4-2f3a6c7b491c)} not attached to a context.
For some reason, the context is available in e.g. onResume() in the PlaceholderFragment:
override fun onResume() {
super.onResume()
// Works fine
Toast.makeText(requireContext(), "placeholder", Toast.LENGTH_LONG).show()
}
fun fabOnClick() {
// Throws exception
Toast.makeText(requireContext(), "placeholder", Toast.LENGTH_SHORT).show()
}
I found this thread, Fragment not attached to a context, in which the solution was to commit a fragment transaction but all of this seems to be handled automatically in this case.

I just fixed an error somewhat similar to you in my code. With the same error you are getting.
The idea is that I was initializing a string variable (NOT in MainActivity) with getResources().
However, the variable was not being initialized with context.getResources()
I was able to initialize this variable inside MainActivity and make it static so that I could just copy the value into the variable NOT inside MainActivity.
So, I think you should search for any variables that you are initializing with getResources and see if you are using a context or not.

when changing singleton fragment, recyclerview has this status?

I'm using singleton fragment. I thought when I call this singleton fragment, the lifecycle methods onCreateView and onActivityCreated will be called only once. But they aren't even though the fragment is singleton, onCreateView and onActivityCreated are called when I call fragment. But I found something strange. That is, the RecyclerView is holding it's position. If I move A frag(using RecyclerView, position at 20) to B frag and redirect to A frag, the A fragment position is 20. Although onCreateView and onActivityCreated are called again, Why the A fragment position is saved?
ps: I know kotlin support singleton class "Objcet". But I'm more comfortable using singleton constructor than object class.
MainActivity
navigation_view.setNavigationItemSelectedListener {
drawerLayout.closeDrawer(GravityCompat.START)
when(it.itemId){
R.id.scheduleFragment->{
changeFragment(scheduleFragment)
}
R.id.noticeFragment->{
changeFragment(NoticeFragment())
}
}
true
}
}
fragment
companion object {
var scheduleFragment: ScheduleFragment? = null
}
fun getInstance(context: Context): ScheduleFragment {
if (scheduleFragment == null) {
scheduleFragment = ScheduleFragment()
}
return scheduleFragment!!
}

Well, it's behaving exactly as expected. The recycler-view's view, position all are members to the fragment instance. So the values remain same as it has only single instance. But the life cycle methods have nothing to do with the fact that the fragment class is singleton. They get called when the specific event happens. For example, when the activity is created then the onActivityCreated method get called by the system and this method calling has nothing to do about the fragment instance creation. Because the fragment instance creation happens earlier when you make an instance of fragment. Now after the use either you want to keep the instance or destroy it, it's your choice. Hope this will clear your confusion. Let me know if you don't understand anything.

How to pass complex, non serializable object to android fragments

Hello fellow Android developers,
I wanna know how do you guys pass complex non serializable (& non parcelable) object to fragments. (such as Listener, Api client, ...)
Let me explain my use case:
The use case
I'm building an Android application composed of one "host" activity and 3 fragments.
Currently I'm passing the object using a custom constructor on the fragment (bad practice I know).
The fragments constructors looks like the following:
/**
* Do not remove ever or you'll face RuntimeException
*/
public FirstFragment() {
}
public FirstFragment(Session session,
ApiClient apiClient,
FirebaseAnalytics firebaseAnalytics) {
mSession = session;
mApiClient = apiClient;
mFirebaseAnalytics = firebaseAnalytics;
}
And I'm using them in the host activity like this
private FirstFragment getFirstFragment() {
if (mFirstFragment == null) {
mFirstFragment = new FirstFragment(mSession, mApiClient, mFirebaseAnalytics);
}
return mHomeFragment;
}
[...]
private void loadFragment(Fragment fragment, String tag) {
FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();
transaction.replace(R.id.frame_container, fragment, tag);
transaction.commit();
}
[...]
private BottomNavigationView.OnNavigationItemSelectedListener mOnNavigationItemSelectedListener
= new BottomNavigationView.OnNavigationItemSelectedListener() {
#Override
public boolean onNavigationItemSelected(#NonNull MenuItem item) {
switch (item.getItemId()) {
case FIRST_FRAGMENT_RES_ID:
toolbar.setTitle(R.string.first_fragment_title);
loadFragment(getFirstFragment(), "first_fragment");
return true;
[...]
}
return false;
}
};
This solution works well almost all the time. But sometimes (and I don't know when exactly) the default constructor is invoked and therefore all local members are null.
Possible solutions
To solve the problem I'm thinking about the following solutions:
Singletons, singletons everywhere
Most of the objects I'm passing are singletons therefore I can access them in the default constructor of the fragments:
public FirstFragment() {
mSession = Session.getInstance(getContext());
mApiClient = ApiClient.getInstance(getContext());
mFirebaseAnalytics = FirebaseAnalytics.getInstance(getContext());
}
Problems
However the above solution wouldn't work if I need to pass a callback or something. How can it be done like this then?
Access the objects using parent activity
I think it's one of the ugliest possible solutions because it will couple the Fragments to the parent activity. The idea is something like this
public FirstFragment() {
mSession = Session.getInstance(getContext());
mApiClient = ApiClient.getInstance(getContext());
mFirebaseAnalytics = FirebaseAnalytics.getInstance(getContext());
mListener = (Listener) getActivity(); // <- will works because parent activity implement the interface
}
Using broadcast & receiver
The idea is to keep passing singleton everywhere and use broadcast & receiver instead of listener.
How do you guys managed this scenario?
Thanks in advance !

You probably want to look into dependency injection (using a tool like Dagger or alternatives), especially for objects like an Api Client. Post the setup, you'd define, just once, how an Api Client instance could be constructed. And later you can use it pretty much everywhere with a one-line statement. The instance is guaranteed to be available upon the fragment instantiation. Further reading: https://dagger.dev/tutorial/

According to your use case, it might be easier to use a ViewModel and store your objects there. Your ViewModel will be shared across your fragments and your host
activity.
See https://developer.android.com/topic/libraries/architecture/viewmodel

Have you considered using "Shared" ViewModel?
Essentially, a sub-class of ViewModel (which is class designed to store and manage UI-related data in a lifecycle conscious way for activities and fragments) can be created like below,
class SharedViewModel : ViewModel()
Inside this class you can have your custom objects with their correct state
Next, in your 1st Fragment you can obtain a handle to this SharedViewmodel like below,
class MasterFragment : Fragment() {
private lateinit var model: SharedViewModel
And obtain the handle to it using below code,
model = activity?.run {
ViewModelProviders.of(this)[SharedViewModel::class.java]
}
You can write your own logic/method/flow inside SharedViewModel to manipulate any custom object's states.
And once all this is done, In your 2nd Fragment, you can create the handle to SharedViewModel similar to above code and using SharedViewModel object you can retrieve the "modified" custom object from same SharedViewModel

It's been several months and I have now come up with a different solution.
For the UI related data
For the UI related stuff I'm now using the androidx livedata
For the complex non serializable data
My use case was to pass complex object to the fragment, such as manager, parent activity (trough a listener), etc... The approach I have taken is by injecting these data manually from the parent activity.
The first things to do was to remove the objects from the fragment constructor and use the default constructor instead, so that I won't face any instantiation errors.
Then I have created an inject() method on the fragment classes that look like this:
public void inject(BillingManager billingManager, Listener listener) {
mBillingManager = billingManager;
mListener = listener;
}
Each fragment will have their own inject method width the objects that should be injected as parameters.
In the parent activity I have override the onAttachFragment() method to handle the fragment attach process:
#Override
public void onAttachFragment(#NonNull Fragment fragment) {
super.onAttachFragment(fragment);
if (fragment.getClass().equals(FirstFragment.class)) {
((FirstFragment) fragment).inject(mBillingManager, this);
} else if (fragment.getClass().equals(HomeFragment.class)) {
((HomeFragment) fragment).inject(this);
}
}
Simple, and now everything work great.

Get parent activity in DialogFragment subclass before show()

I am working on an android application with many dialogs, all of which extend a custom class called "DialogFragmentBase" which extends the library's "DialogFragment". All activities use the show() method overridden in DialogFragmentBase.
I want to prevent showing the dialogs if the parent activity is backgrounded (as in receiving a phone call) since that results in the illegalStatEexception, but at the same time I don't want to guard every show() call in the application with:
if(getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED))
So I wanted to do something like this in the DialogFragmentBase:
#Override
public void show(FragmentManager manager, String tag){
List<Fragment> fragments = manager.getFragments();
if(fragments != null && fragments.size() > 0){
FragmentActivity activity = fragments.get(fragments.size()-1).getActivity();
if(activity != null && activity.getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED)){
super.show(manager, tag);
}
}
}
So my question is: Is accessing the previous fragment like that considered a bad practice? It does work...but I remember reading somewhere that fragments shouldn't intercommunicate. If it is indeed a bad practice, what would be a better solution that can be implemented in the DialogFragmentBase (to avoid adding guards everywhere).
Note: I tried the onSaveInstanceState solution described here, but since the DialogFragment hasn't been shown yet, the onSaveInstanceState isn't called for it at that point. Also getActivity() returns null since onAttach hasn't been called yet at that point.
Thanks!

The support library FragmentManager has an isStateSaved() method. Depending on exactly what your requirements are, you could leverage this to check if it is "safe" to show your dialogs:
#Override
public void show(FragmentManager manager, String tag) {
if (!manager.isStateSaved()) {
super.show(manager, tag);
}
}
Note that the above implementation is relatively similar to using commitAllowingStateLoss(), in that you'll silently fail to show your dialog in certain cases. But perhaps that is fine for your requirements.

Perhaps you could create a new method in your dialog base class:
public void showIfResumed(FragmentActivity activity, String tag) {
if (/* your check here, e.g. activity.getLifecycle()... */) {
show(activity.getSupportFragmentManager(), tag);
}
}
And then, in your activities, rather than calling show(getSupportFragmentManager(), TAG), you could call showIfResumed(this, TAG). You'll still have to change every call to show() to a call to showIfResumed(), but this would reduce the code duplication considerably.

Fragment loses Activity while networking (android)

I initiate most of my networking calls from Fragments and then use callbacks to tell the Fragment whether or not the networking task succeeded or failed and to update ui accordingly.
On rare occassions (.25% of sessions) my program is crashing with a null-pointer exception due to getActivity() returning null when the code in my callback runs. I know that I can use a null check on getActivity() to prevent this from happening, however what's the best practice for handling this issue?
The null check seems to be little more than a crash prevention tool as the program still needs the data from the networking task.
The code looks something like the following:
private void queryServer() {
// networking task should query server for user id, if successful store it
// in user preferences to be accessed by fragment in callback
new networkingTask(new VolleyCallback() {
#Override
public void onSuccess() {
// code below needs null check on getActivity - but what else?
mUserId = new UserPreferences(getActivity()).getUserId();
}
#Override
public void onFail() {
// booooo
}
});
}

As I stated in my comment above, what is likely happening is the Activity/Fragment pair are being stopped or destroyed by the system. This will happen for a variety of reasons, such as a screen orientation change. Because your handler is a method on the fragment object, you are working with a "dead" fragment by the time the call returns. There are several patterns for dealing with this. In short you need to make your handler aware of the current fragment, and you can accomplish this by using lifecycle methods.
Below is an example of a pattern you could use. I tried to make the example as minimal as possible.
import android.app.Activity;
import android.app.Fragment;
public class MyFragment extends Fragment {
// This is static so that it will not go out of scope when the original
// fragment is destroy. This allows it to be access from all MyFragment
// instances.
static MyResponseProcessor processor = new MyResponseProcessor();
// This will be the class that handles your network call.
public static class MyResponseProcessor {
// This instance variable is alway a reference to the currently displayed fragment.
private Fragment activeFragement;
public void setActiveFragement(Fragment activeFragement) {
this.activeFragement = activeFragement;
}
// This method, which is for demonstration purposes, shows how you would handle a network response.
public void handleResponse(SomeResponseObject) {
if (activeFragement != null) {
// Now you can get the activity
Activity activity = activeFragement.getActivity();
} else {
// Yes it is possible that there is no active fragment.
// If the user has stayed on the same screen, then the
// fragment of interest will likely be re-created, and
// this window of time with no fragment will be brief.
//
// Note that this null-check is very different than the
// null-check you describe. In your case the reference is
// guaranteed to be null forever. In this case, the reference
// will eventually become non-null.
}
}
}
#Override
public void onStart() {
super.onStart();
// At this point in the fragment lifecycle, the fragment is both running and is attached to an Activity.
// Thus "getActivity" calls are safe from this point onward.
processor.setActiveFragement(this);
}
#Override
public void onStop() {
super.onStop();
// At this point in the fragment lifecycle, the fragment has been stopped and is about to lose its connection to the activity.
// So after this point, calls to "getActivity" are probably not safe.
// DISCLAIMER - I have not tested this. You might want to do this in a
// different method such as "onDestroyView()"
processor.setActiveFragement(null);
}
}