1

I'm creating FrameLayouts and Fragments at runtime. I have a LinearLayout (R.id.presentationRight) in my xml file. Every time I need a new fragment within that layout, I do the following.

  • Create a new FrameLayout and add it to the LinearLayout
  • Generate an ID for the FrameLayout so FragmentTransaction can reference it
  • Create a new Fragment
  • Perform a FragmentTransaction to place the new Fragment in the new frame.

The code looks like this

LinearLayout presentationRight = (LinearLayout) findViewById(R.id.presentationRight);
FrameLayout bluRayFrame = new FrameLayout(MainActivity.this);
bluRayFrame.setId(View.generateViewId());
presentationRight.addView(bluRayFrame);

BluRayFragment bluRayFragment = new BluRayFragment();

FragmentTransaction fragmentTransaction = getSupportFragmentManager().beginTransaction();
fragmentTransaction.replace(bluRayFrame.getId(), bluRayFragment);
fragmentTransaction.commit();

It works perfectly. I can run as many copies of this method as I want and it always adds another instance of this fragment to the LinearLayout, which is exactly what I want.

The problem comes when the screen rotates. When I had a single existing frame in the layout and I was just replacing the existing frame, rotation worked perfectly. You could view the app in portrait or landscape and it always reloaded the fragment perfectly. However, now that the framelayout I'm addressing isn't actually in the XML file, it crashes the app and gives me a null pointer within the Fragment itself when it tries to reference container.getContext(). I'm assuming that since the Fragment isn't actually tied to the xml file that when the Activity reloads on rotate, the container isn't there so the context isn't there, but I don't know how to fix it.

I'm not doing anything special to handle the rotation right now, just letting the activity do everything on it's own.

Thoughts? I'd really like to avoid creating a bunch of framelayouts in code and referencing them individually because i don't know how many of these fragments will eventually be necessary, so writing it open ended seems like the best way to handle things if I can figure out how.

Jeff McAleer
  • 354
  • 2
  • 12
  • OK I found [this question](http://stackoverflow.com/questions/11853389/android-fragments-retaining-data) that gave me the following line of code. android:configChanges="keyboardHidden|orientation|screenSize" This is working, but the rest of that answer seems to suggest that this is not good practice and I need to be retaining things instead. It looks like I should be using onSaveInstanceState to do this, but I'm not at all sure how to store this data because I'm not actually retaining it myself within the activity (the above code is in a method that gets called repeatedly) – Jeff McAleer Oct 02 '15 at 19:07
  • Still working on this, making some progress I think. I can create an ArrayList that I add and remove the IDs to, and then I can pass that ArrayList through the bundle in onSaveInstanceState() and end up with those IDs in the onCreate. Once I'm there, though, I'm not sure what to do with them. If I can stop my existing fragments from recreating themselves and failing to find a context, I can just recreate them, but I don't know how to do that. I suspect passing the context to those fragments would be better than recreating anyway, but I'm still somewhat lost there. – Jeff McAleer Oct 02 '15 at 21:42
  • Still working on it: added setRetainInstance(true); to my fragment's onCreate method, as suggested [here](http://developer.android.com/guide/topics/resources/runtime-changes.html). It still doesn't work, but I'm making progress. Now logcat is giving me a Resource Not Found Exception for resource ID #0x1, which I'm betting is the auto generated ID. I'm sure I can retain that idea through onSaveInstanceState but I still don't know how to get it back to the fragment that needs it. – Jeff McAleer Oct 02 '15 at 21:49
  • So what was your final solution? – arslancharyev31 Jul 24 '17 at 21:09
  • I don't think I ever solved it. This project got shelved shortly after my most recent post, and I don't have the code handy to check. Sorry :( – Jeff McAleer Jul 25 '17 at 22:16
  • Ok. No problem :) – arslancharyev31 Jul 25 '17 at 22:21

0 Answers0