3

Alright. My first question here. And I already found some solution, but honestly do not really get the stuff that happens in the background. So perhaps there’s someone who could clear up this stuff a little bit. After days of debugging I’m just glad that it works... and hope I did not make some serious error. So let’s have a look.

I got some Main-Activity. Just a FragmentActivity extending JFeinstein’s SlidingFragmentActivity. Further I decided to go the fragment-way and just put any content (list-fragment, article-fragment, …) as a fragment into a container (to right of the sliding-menu); my main-container. So far, so good.

One essential fragment is my article-fragment. A ViewPager (with a FragmentStatePagerAdapter) - containing some pages with text and perhaps another list-fragment. Still no problem so far, until I decide to rotate the device. And to be more precise, rotating the device works too as long as I do not decide to update my article-fragment.

I understood (correct me if I am wrong) that Android handles the fragments state on its own when rotating the device. And it seems to be everything fine just until I want to reload/update its content.

Ok let’s dig deeper into that. On first start I got some empty main-container. Then I am loading my article-fragment for the first time. Just getting the SupportFragmentAdapter, creating my ArticleFragment and replace the main-container with the newly created fragment - tagged. No rocket-science - just a simple transaction:

ViewPagerFragment pagerFragment = (ViewPagerFragment) 
    getSupportFragmentManager().findFragmentByTag(TAG_FRAGMENT_ARTICLE);

if(pagerFragment != null){
    if(pagerFragment.isResumed()){
        pagerFragment.triggerReload();
    }
} else {
    pagerFragment = new ViewPagerFragment();
    FragmentTransaction t = getSupportFragmentManager().beginTransaction();
    t.replace(R.id.id_main_root_frame, pagerFragment, TAG_FRAGMENT_ARTICLE);
    t.commitAllowingStateLoss();
}

To avoid creating a fragment each time I reload my content, I’m trying to fetch the fragment before the transaction and - if it is found and resumed - trigger some reload on the existing fragment.

Now I rotate my device in this state. To avoid messing with the fragment state I left onSaveInstanceState() inside the fragment untouched. So I guess the fragment is just destroyed and recreated. And everything still works so far. But I think this part has something of a black box.

After that - normal startup, creating fragment and put into main-container, rotating device - I trigger some update. But instead of finding the old (recreated) fragment by tag, nothings found and a new fragment is created and inserted. At least tried to be inserted, because this is where I got the following exception:

java.lang.IllegalStateException: Activity has been destroyed

To be precise, I get the above exception when finish my transaction with a commitAllowingStateLoss(). When I just commit() the transaction I get the following exception:

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState

So that’s where the error comes up. And after ages of debugging and searching I found some hint on this question/answer to get the SupportFragmentManager on a WeakReference of my MainActivity. And what should I say. Since I implemented that, it works. I had to change my update-process a bit, but it works. But leaves some questions ...

The behaviour seems to be similiar. First creation works perfect. Reload just the same - fragment is found by tag. After rotation, article is still shown. And when I reload the fragment with that state it is not found by tag so a new one is created, but the commit()-request does not throw an exception. A look inside the debugger shows that the WeakReference is some other instance (other id), than the one(this) all of this takes place in. And thats where I lose the plot. ..

If some of you could give me some hints, would be great! Thanks in advance!

Community
  • 1
  • 1
mauricemoss
  • 150
  • 3
  • 9
  • I have the exact same issue and not the slightest clue why it is behaving this way. Super frustrating since none of this stuff is documented. – dcow Aug 26 '13 at 21:23

1 Answers1

0

try this:

commitAllowingStateLoss(); instead commit();
FelixSFD
  • 6,052
  • 10
  • 43
  • 117
Mehatab
  • 1,689
  • 1
  • 11
  • 6