I’ve looked through the similar questions and not yet found an answer. I will eventually be adding each of my Views after acquiring data from a SQL db, but for now, I am simply trying to add a set of views so I can get my layout working. I have a main activity with a fragment manager that gets my tabs flowing and loading just fine, so I don’t think I need to provide that code here.
Here is the code for the fragment:
public class EconFragment extends Fragment {
private ViewGroup container;
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
populateQuestions(container, inflater);
return inflater.inflate(R.layout.econfragment, container, false);
}
public void onPause() {
super.onPause();
container.removeAllViews();
}
private void populateQuestions(ViewGroup v, LayoutInflater inflater) {
container = v;
int count = 10;
int runner = 0;
while (runner < count) {
View question = inflater.inflate(R.layout.question, null);
question.setLayoutParams(new LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.WRAP_CONTENT));
container.addView(question, runner);
runner++;
}
}
}
So while this should populate in more than one Question.xml View into the container, I only have one show up. It’s interesting to note that I can observe the delay as runner increases up to count, but again, only one question view shows up. When I change things up, I get a lot of null pointers around my TableLayout, so I have removed that portion.
Ultimately, EconFragment‘s xml has a Table Layout with a ScrollView which has another TableLayout, questionContainer.
I had hoped originally to add each question view as a row in questionContainer, but that’s giving me all sorts of trouble. I posit that it’s somewhat related to calling populateQuestions() prior to the return statement in onCreateView()?
Here is how I solved the problem. It doesn’t implement the SQL dB access that I desire, it just has a filler while loop and a dummy array of strings to make the Table Rows. I’m almost done implementing the login/register via SQL dB, and as soon as that’s done, populating these tablerow’s via SQL shouldn’t be a big problem.