I'm getting this on some cases, in onResume(), of an activity which uses a FragmentStatePagerAdapter. When using device's back button. Not always. Not reproducible.
I'm using support package v4, last revision (8).
Already searched with google, no success finding a useful answer.
Looking in the source, it's thrown here: FragmentManager.java
#Override
public void putFragment(Bundle bundle, String key, Fragment fragment) {
if (fragment.mIndex < 0) {
throw new IllegalStateException("Fragment " + fragment
+ " is not currently in the FragmentManager");
}
bundle.putInt(key, fragment.mIndex);
}
But why is the index of fragment < 0 there?
The code instantiating the fragments:
#Override
public Fragment getItem(int position) {
Fragment fragment = null;
switch(position) {
case 0:
fragment = MyFragment.newInstance(param1);
break;
case 1:
fragment = MyFragment2.newInstance(param2, param3);
break;
}
return fragment;
}
#Override
public int getCount() {
return 2;
}
If your ViewPager is layouted inside a fragment (not an activty) :
mViewPager.setAdapter(new MyFragmentStatePagerAdapter(getChildFragmentManager()));
I had the same error here, but for another reason.
In my case I had override getItemPosition in my FragmentStatePagerAdapter. My ideia was to return the position, if the item exists, or a POSITION_NONE, if it doesn't exists anymore.
Well, my problem was the fact that when my collection got empty I returned POSITION_NONE. And that broke everything.
My fix was to return POSITION_UNCHANGED when I had an empty collection.
Hope it helps someone else.
The two key things to understand the bug are:
It happens sometimes.
It happens in onResume().
Given this information, it's likely that the ViewPager is not retaining the state of your Fragments. If you are manipulating the Fragments directly from the Activity, it could be the case that the off-page Fragment is getting destroyed and your Activity is trying to manipulate a null fragment. To retain the Fragment's state even when it is not in the current screen, the fix is pretty simple:
private static final int NUM_ITEMS = 2;
ViewPager mPager = /** instantiate viewpager **/;
mPager.setOffscreenPageLimit(NUM_ITEMS-1);
You can read about it here:
ViewPager Fragments getting destroyed over time?
Got it, the reason was, that I'm intantiating the Adapter each time in onResume().
If I instantiate the adapter only once, in the life cycle of the activity, this does not happen anymore.
This exceptions means that you are trying to attach a fragment to an activity which is no longer correct state to attach the fragments. What it means is, whenever we try to attach fragments (especially through an asynchronous call), there is a small probability that someone has pressed the back button and activity is in merge of getting destroyed while you are attaching the fragment. This is not always reproducible as its just a race condition, and might not always occur..
There are two ways to fix this:
1) This happens when you the onSaveInstanceState of your activity has been called and post to that you are trying to attach the fragment, since android wont be able to save the state of your fragment now, it will throw an exception. To overcome this and if you are not saving the state of your fragment, try using
commitAllowingStateLoss(), while committing the transaction.
2) To be very safe, check whether your activity is in correct state or not before attaching the fragment, use the following code in onPause:
boolean isInCorrectState;
public void onCreate{
super.onCreate();
isInCorrectState = true;
}
public void onPause() {
super.onPause();
if(isFinishing()){
isInCorrectState = false;
}
}
Now use this flag to check if your activity is in correct state or not before attaching the fragment.. Meaning attach the fragment iff isInCorrectState == true.
For me the reason was something else.
In my Loader.onLoaderReset() I cleared the data from the adapter. When I was leaving the app, onDestroy() caused the loader to reset, which cleared the FragmentStatePagerAdapter. I think it caused the adapter to clear all references to it's Fragments, but somehow, the FragmentManager didn't notice and threw the Exception. Doesn't seem very logical to me.
Note that for me it happened Activity.onDestroy().
Hope it helps someone.
Fragments in the ViewPager are fixed, instead of trying to replace the fragments in the adapter, try to give a different set of fragments and notifyDataSet changed, or take the advantage of FrameLayout to show another fragment over the view pager tab's current fragment.
There is my solution that works:
Swipe Gesture applied at Fragment level along with ViewPager with it's default swipe disabled
Related
I have a viewpager2 with multiple fragments in FragmentStateAdapter. Whenever I try to open a new fragment and then go back to my current one with viewpager2, I get an exception:
Expected the adapter to be 'fresh' while restoring state.
It seems FragmentStateAdapter is unable to properly restore its state as it is expecting it to be empty.
What could I do to fix this ?
it can be fixed by viewPager2.isSaveEnabled = false
So my problem was that I was creating my FragmentStateAdapter inside my Fragment class field where it was only created once. So when my onCreateView got called a second time I got this issue. If I recreate adapter on every onCreateView call, it seems to work.
I encountered the same problem with ViewPager2. After a lot of efforts on testing different methods this worked for me:
public void onExitOfYourFragment() {
viewPager2.setAdapter(null);
}
When you come back to the fragment again:
public void onResumeOfYourFragment() {
viewPager2.setAdapter(yourAdapter);
}
This adapter/view is useful as a replacement for FragmentStatePagerAdapter.
If what you seek is to preserve the Fragments on re-entrance from the Backstack that would be extremely difficult to achieve with this adapter.
The team placed to many breaks in place to prevent this, only god knows why...
They could have used a self detaching lifeCycle observer, which ability was already foresaw in its code, but nowhere in the android architecture makes use of that ability....
They should have used this unfinished component to listen to the global Fragments lifecycle instead of its viewLifeCycle, from here on, one can scale the listening from the Fragment to the viewLifeCycle. (attach/detach viewLifeCycle observer ON_START/ON_STOP)
Second... even if this is done, the fact that the viewPager itself is built on top of a recyclerView makes it extremely difficult to handle what you would expect from a Fragment's behavior, which is an state of preservation, a one time instantiation, and a well defined lifecycle (controllable/expected destruction).
This adapter is contradictory in its functionality, it checks if the viewPager has already been fed with Fragments, while still requiring a "fresh" adapter on reentrance.
It preserves Fragments on exit to the backStack, while expecting to recreate all of them on reentrance.
The breaks on place to prevent a field instantiated adapter, assuming all other variables are already accounted for a proper viewLifeCycle handling (registering/unregistering & setting and resetting of parameters) are:
#Override
public final void restoreState(#NonNull Parcelable savedState) {
if (!mSavedStates.isEmpty() || !mFragments.isEmpty()) {
throw new IllegalStateException(
"Expected the adapter to be 'fresh' while restoring state.");
}
.....
}
Second break:
#CallSuper
#Override
public void onAttachedToRecyclerView(#NonNull RecyclerView recyclerView) {
checkArgument(mFragmentMaxLifecycleEnforcer == null);
mFragmentMaxLifecycleEnforcer = new FragmentMaxLifecycleEnforcer();
mFragmentMaxLifecycleEnforcer.register(recyclerView);
}
where mFragmentMaxLifecycleEnforcer must be == null on reentrance or it throws an exception in the checkArgument().
Third:
A Fragment garbage collector put in place upon reentrance (to the view, from the backstack) that is postDelayed at 10 seconds that attempts to Destroy off screen Fragments, causing memory leaks on all offscreen pages because it kills their respective FragmentManagers that controls their LifeCycle.
private void scheduleGracePeriodEnd() {
final Handler handler = new Handler(Looper.getMainLooper());
final Runnable runnable = new Runnable() {
#Override
public void run() {
mIsInGracePeriod = false;
gcFragments(); // good opportunity to GC
}
};
mLifecycle.addObserver(new LifecycleEventObserver() {
#Override
public void onStateChanged(#NonNull LifecycleOwner source,
#NonNull Lifecycle.Event event) {
if (event == Lifecycle.Event.ON_DESTROY) {
handler.removeCallbacks(runnable);
source.getLifecycle().removeObserver(this);
}
}
});
handler.postDelayed(runnable, GRACE_WINDOW_TIME_MS);
}
And all of them because of its main culprit: the constructor:
public FragmentStateAdapter(#NonNull FragmentManager fragmentManager,
#NonNull Lifecycle lifecycle) {
mFragmentManager = fragmentManager;
mLifecycle = lifecycle;
super.setHasStableIds(true);
}
I've faced the same issue.
After some researching I've came to that it was related to instance of Adapter. When it is created as a lazy property of Fragment it crashes with that error.
So creating Adapter in Fragment::onViewCreated resolves it.
I was also getting this java.lang.IllegalStateException: Expected the adapter to be 'fresh' while restoring state. when using ViewPager2 within a Fragment.
It seems the problem was because I was executing mViewPager2.setAdapter(mFragmentStateAdapter); in my onCreateView() method.
I fixed it by moving mViewPager2.setAdapter(mMyFragmentStateAdapter); to my onResume() method.
I solved this problem by testing if it is equal null
if(recyclerView.adapter == null) {recyclerView.adapter = myAdapter}
I've been struggling with this and none of the previous answers helped.
This may not work for every possible situation, but in my case fragments containing ViewPager2 were fixed and few, and I solved this by doing fragment switch with FragmentTransaction's show() and hide() methods, instead of replace() commonly recommended for this. Apply show() to the active fragment, and hide() to all others. This avoids operations like re-creating views, and restoring state that trigger the problem.
I got this problem after moving new SDK version. (Expected the adapter to be 'fresh' while restoring state)
android:saveEnabled="false" at ViewPager2 can be a quick fix but it may not be what you want.
<androidx.viewpager2.widget.ViewPager2
android:saveEnabled="false"
Because this simply means your viewPager2 will always come on the first tab when your activity is recreated due to the same reason you are getting this error ( config change and activity recreate).
I wanted users to stay wherever they were So I did not choose this solution.
So I looked in my code a bit. In my case, I found a residual code from early days when I was just learning to create android app.
There was a useless call to onRestoreInstanceState() in MainActivity.onCreate, I just removed that call and it fixed my problem.
In most cases, you should not need to override these methods.
If you want to override these , do not forget to call super.onSaveInstanceState / super.onRestoreInstanceState
Important Note from documentation
The default implementation takes care of most of the UI per-instance
state for you by calling View.onSaveInstanceState() on each view in
the hierarchy that has an id, and by saving the id of the currently
focused view (all of which is restored by the default implementation
of onRestoreInstanceState(Bundle)). If you override this method to
save additional information not captured by each individual view, you
will likely want to call through to the default implementation,
otherwise be prepared to save all of the state of each view yourself.
Check if the information you want to preview is part of a view that may have an ID. Only those with an ID will be preserved automatically.
If you want to Save the attribute of the state which is not being saved already. Then you override these methods and add your bit.
protected void onSaveInstanceState (Bundle outState)
protected void onRestoreInstanceState (Bundle savedInstanceState)
In latest SDK versions Bundle parameter is not null, so onRestoreInstanceState is called only when a savedStateIsAvailable.
However, OnCreate as well gets savedState Parameter. But it can be null first time, so you need to differentiate between first call and calls later on.
Change your fragmentStateAdapter code from
MyPagerAdapter(childFragmentManager: FragmentManager,
var fragments: MutableList<Fragment>,
lifecycle: Lifecycle
) : FragmentStateAdapter(childFragmentManager,lifecycle)
to
MyPagerAdapter(fragment: Fragment,
var fragments: MutableList<Fragment>
) : FragmentStateAdapter(fragment)
Note: Here we are removing lifecycle and fragmentManager dependency and fragment state gets restored on back press.
I have a ViewPager in my app, this viewpager contains 10 same fragments with different arguments. Using FragmentStatePagerAdapter as the viewpager's adapter. FragmentStatePagerAdapter pre-make new instance when a page are selected and then destroy it. But I don't need 10 instances. 3 is enough. When user scroll to right, most left fragment can be reused, because GC are expensive. How to achieve it?
When you override the getItem function of the FragmentStatePagerAdapter, maintain a reference to each of the fragments, and instantiate them only if null:
private MyFragment myFragment0, myFragment1, myFragment2, ...;
#Override
public Fragment getItem(int position) {
switch (position) {
case 0:
if (myFragment0 == null) {
myFragment0 = new MyFragment();
}
return myFragment0;
case 1:
if (myFragment1 == null) {
myFragment1 = new MyFragment();
}
return myFragment1;
case 2:
if (myFragment2 == null) {
myFragment2 = new MyFragment();
}
return myFragment2;
...
}
}
Each of the 10 fragments will only be instantiated once, and each of the 10 fragments will only be instantiated once the user is 1 swipe away from viewing it.
Calling viewPager.setOffscreenPageLimit(10) like a different user suggested has a similar effect, but it actually results in instantiating all 10 fragments as soon as you set the adapter, which is likely to freeze the app for a short while and therefore not recommended.
As far as I know, unless your fragment instance has a ton of properties, destroying and creating the instances shouldn't be much of a problem. (Especially considering modern android devices with high power CPU and RAM)
But to answer your 'how to achieve' question...
You need a pool to manage the fragment instances. This will create, retain, and destroy (when necessary) the fragment instances.
Whenever ViewPagerAdapter.getItem() is called, get a fragment instance from the pool and return it.
If the pool has less than 3 instances, create one and return it. Otherwise, return an instance that is no longer used.
To determine an instance that is no longer used, keep track of which fragment instance represents which page, what the current page is, and which way the page is about to be viewed.
Now this is basic logic behind it, but is it really worth implementing all (especially #4).
I'm really sorry that I could not show you the actual code snippets since I've never tried to implement such way.
Hope it helps.
I'm currently dealing with an issue with Android & It's Re-Creation Cycle on screen rotation:
I have one single Activity and lots of Fragments (Support-V4) within.
For example, the Login it's on a Single Activity with a Fragment, when the logs-in then the App changes it's navigation behavior and uses multiple fragments, I did this, because passing data between Fragment A to Fragment B it's way much easier than passing data Between an Activity A to an Activity B.
So My issue it's presented when I rotate the device, on my first approach, the initial fragment was loaded, but what would happen, if the user it's on Page 15 and it rotates it's device, it would return to Fragment 1 and give a very bad user-experience. I set all my fragments to retain their instance and added this on the MainActivity on Create:
#Override
protected void onCreate(Bundle savedInstanceState) {
// TODO Auto-generated method stub
super.onCreate(savedInstanceState);
setContentView(R.layout.main_layout);
initBackStackManager();
initControllers();
mayDownloadData();
setTitle();
if(savedInstanceState == null){
addAreaFragment();
}
}
Now, the first fragment is not loaded after screen orientation change, but If I try to make a fragment transaction, it says Can not perform FragmentTransaction.commit() after onSaveInstanceState(), is there a way to handle this? Or Do I really really need to use multiple Activities with a Fragment embedded within?
Thank you very much!
EDITED
I forgot to add that this happens only on a specific Fragment... For example I have the following fragment flow:
AreaFragment -> WaiterSelectionFragment -> WaiterOptionsFragment.
If I'm in the AreaFragment and I rotate the device I can still add/replace fragments and nothing happens, no error it's being thrown. If I'm on the WaiterSelectionFragment no error happens too. BUT, If I'm on the WaiterOptionsFragment the error it's being thrown. The WaiterSelectionFragment has the following structure:
LinearLayout
FragmentTabHost
Inside the FragmentTabHost there are some fragments, and that's where the error it's happening. You might wonder Why FragmentTabHost? easy, the Customer wants that App to show the TabBar, If I use Native Android Tabs the Tabs get rearranged to the ActionBar when on
Landscape position.
EDIT 2
I've used the method provided by #AJ Macdonald, but no luck so far.
I have my Current Fragment being saved at onSaveInstanceState(Bundle) method and restore my fragment on onRestoreInstanceState(Bundle) method on the Android Activity, I recover my back button and the current Fragment but when I get to the third Fragment the error still occurs. I'm using a ViewPager that holds 4 Fragments, Will this be causing the Issue? Only on this section of the App Happens. I've 4 (main workflow) fragments, on the First, Second and Third Fragment no error it's being presented, only on the ViewPager part.
Give each of your fragments a unique tag.
In your activity's onSaveInstanceState, store the current fragment. (This will probably be easiest to do if you keep a variable that automatically updates every time the fragment changes.)
In your activity's onCreate or onRestoreInstanceState, pull the tag out of the saved bundle and start a new fragment of that type.
public static final int FRAGMENT_A = 0;
public static final int FRAGMENT_B = 1;
private int currentFragment;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//other stuff
if(savedInstanceState == null){
addAreaFragment();
currentFragment = FRAGMENT_A;
}else{
currentFragment = savedInstanceState.getInt("currentFragment");
switch(currentFragment){
case FRAGMENT_A:
addAreaFragment();
break;
case FRAGMENT_B:
addFragmentB();
}
}
}
// when you switch fragment A for fragment B:
currentFragment = FRAGMENT_B;
#Override
public void onSaveInstanceState(Bundle savedInstanceState) {
savedInstanceState.putInt("currentFragment", currentFragment);
super.onSaveInstanceState(savedInstanceState);
}
A suggestion to try is to use FragmentTransaction.commitAllowingStateLoss() in place of FragmentTransaction.commit(). That should stop the Exception from being thrown, but the downside is if you rotate the device again the most recent state of the UI may not return. That is a suggestion given that I am not sure of the effect of using FragmentTabHost, if it has any effect at all.
Using Tabs means using fragments, and for some reason fragments have new steps in their life cycle, like onAttach(Activity).
My fragment fills up some maps from the resources, and it is done on onAttach() instead of the fragment constructor; because in the constructor getResources() throws an exception due to the lack of Activity yet.
The fragment is created on MainActivity like this:
#Override
public void onTabSelected(ActionBar.Tab tab, FragmentTransaction fragmentTransaction) {
switch( tab.getPosition() ) {
case 0:
if( fragmentTab0 == null ) {
fragmentTab0 = new MyFragment();
setTabText(0, ((MyFragment)fragmentTab0).getMyName());
}
fragmentTransaction.add(R.id.fragmentContent, fragmentTab0, "TAB0");
break;
Here lies my problem, in the call to the fragment method getMyName() which uses the maps I mentioned before to get a string. The call to getMyName() is executed before the fragment's onAttach() and the maps are not ready yet.
I am sure I can find a convoluted way to get the name (actually I tried already to pass the activity to the fragment's constructor and built the maps there, and it works, but it goes against the fragment philosophy).
I would have thought that the activity should be visible during Fragment constructor, since the fragments are created from the activity they're going to be eventually attached, so there is no point in delaying the activity attachment.
I also would have thought that the call to new MyFragment() should return after onAttach() is done. But it returns right after the constructor is done.
Therefore I feel not comfortable with the situation and I wonder if I am using fragments the wrong way, if so, the question is, how am I supposed to do it right to be able to call getMyName() there.
Note: From the fragment life cycle diagram it is clear that onAttach() and onDetach() are indistiguishable from onCreate() and onDestroy() respectively, so I question if they are really necessary.
onAttach() is not invoked until the fragment transaction is committed. Until then, a fragment has no reference to the creating Activity unless you pass it such a reference. Passing that reference is probably the cleanest way to implement what you're trying to do.
Generally in Android the title is dictated by the containing activity, not the fragment. For example, a PreferenceActivity's xml headers file lists titles and their associated fragments; those titles do not appear in the preference xml files used by the PreferenceFragment.
In my application, I use an Activity which holds one Fragment with FragmentTabHost and hence all its tabs are nested Fragments.
Inside an Activity which holds a Fragment with its nested Fragment, we may get a reference to attached one using onAttachedFragment().
But how to get a reference to nested Fragment from FragmentTabHost?
Well, exploring the source code of FragmentTabHost I've found that when it adds a fragment tab, it assignes a tag of TabSpec to nested Fragment.
So to get the reference to this Fragment we should call
getChildFragmentManager().findFragmentByTag(tabSpecTag)
I was trying this for a while, but I was getting null returned from the FragmentManager because I was trying to access the manager in onCreateView() immediately after adding.
Here is a good explanation on what happened
It's also important to note that Fragment tabs that have not yet been selected don't exist yet in the FragmentManager, and so will return null as well. I got around this by calling mTabHost.setCurrentTab(index) before trying get to the Fragment with the FragmentManager. It's not very clean, but it works.
Above solutions are also working but I have one more easy solution,
#Override
public void onTabChanged(final String tabId) {
new Handler().postDelayed(new Runnable() {
#Override
public void run() {
mFragment = getChildFragmentManager().findFragmentByTag("Tagname");
}
},1000);
}
Here you have to implement FragmentTabHost.onTabChangeListener
We have kept a second delay in fetching fragment from the childFragmentManager.
Note : You need to cast mFragment which fragment you have used.
I found a solution that I like a little better because it doesn't involving executing code with a delay (which is always iffy given android hardware fragmentation and different processor speeds).
In your onTabChanged() method, before you try to find the fragment, call executePendingTransactions() on the fragment manager associated with your tabHost. It seems there are some places in the FragmentTabHost source code where they should be calling executePendingTransactions() but fail to do so.
This works every time the tab changes with one exception... the first tab that is selected still comes back null... In my specific case, I was able to handle this exception differently anyway, by putting some code in onResume.
Hope this helps.