Im having a customized ArrayAdapter for a spinner in my app.
Here's the code for its getDropDownView() method:
#Override
public View getDropDownView(int position, View convertView,ViewGroup parent) {
View vista = convertView;
if (vista==null) {
LayoutInflater inflater = (LayoutInflater) getContext().getSystemService(Context.LAYOUT_INFLATER_SERVICE);
vista = inflater.inflate(R.layout.row_spinner,null);
}
TextView tv = (TextView) vista.findViewById( R.id.textview_entry );
if( !Utils.isSDKAbove( Utils.HONEY_COMB ) )
{
tv.setTextColor( getContext().getResources().getColor( android.R.color.primary_text_light ) );
}
tv.setText( getItem( position ) );
return vista;
}
and when tv.setText(), it throws the NullPointerException for TextView.
However , when I changed the
vista = inflater.inflate(R.layout.row_spinner, null);
to
vista = inflater.inflate(R.layout.row_spinner, parent, false);
it works.
can someone explain a bit more about the difference between the two different signature of the methods?
By declaring a parent root view, you are supplying a parent xml layout for that view. The third boolean parameter then determines whether or not this child view is attached to the parent view. Thereby determining whether child inherits the parent view's touch methods or not.
Either way the view needs to be put into perspective in terms of xml layout, so that the customisations and xml structure you've made will be implemented throughout your view hierarchy.
Using inflate (layout, parent, false)
You are using the parent layout to inflate the view (in this case spinner)
without attaching it to the parent view.
Using null you are not giving the view any layout parameters so the layout parameters for the xml for the textview doesn't exist.
From the docs:
root Optional view to be the parent of the generated hierarchy
(if attachToRoot is true), or else simply an object that provides
a set of LayoutParams values for root of the returned hierarchy
(if attachToRoot is false.)
attachToRoot Whether the inflated hierarchy should be
attached to the root parameter? If false, root is only used to
create the correct subclass of LayoutParams for the root view in the XML.
Returns
The root View of the inflated hierarchy.
If root was supplied and attachToRoot is true,
this is root; otherwise it is the root of the inflated XML file.
Using null is not good way to detach a view from the parent view, unless it is a stand alone feature, like an alert dialog.
The view needs a root view, passing null works some of the time, but only because the program attempts to create default xml parameters for the view.
This article goes into more detail.
So why do you suppose we are given this ViewGroup if we are not supposed to attach to it? It turns out the parent view is a very important part of the inflation process because it is necessary in order to evaluate the LayoutParams declared in the root element of the XML being inflated. Passing nothing here is akin to telling the framework “I don’t know what parent this view will be attached to, sorry.”
The problem with this is android:layout_xxx attributes are always be evaluated in the context of the parent view. As a result, without any known parent, all LayoutParams you declared on the root element of your XML tree will just get thrown away, and then you’ll be left asking “why is the framework ignoring the layout customizations I defined? I’d better check SO and then file a bug.”
For an important reason, i'm required to keep only a single instance of a View in the entire application.
Within the application there will be multiple parent views, (each displayed only once at at time). And I need to move the child view around - to the currently active parent.
I tried doing the following:
if (view_to_move_around != null) {
ViewGroup oldParent = (ViewGroup) view_to_move_around.getParent();
if (oldParent != null) {
oldParent.removeView(view_to_move_around);
}
} else {
// Initialise the View
}
newParent.addView(view_to_move_around)
However, that method didn't seem to work? Completely stuck at this point.
I guess my question will be "What do you mean it's not working?" Are you getting an exception? It is not being displayed properly? Does it execute without issue, but is not displaying? Does it display, but it's always initializing?
Are you manipulating the child view within each parent view, before you pass it on to the next view?
Few things to make sure right off the bat:
Layout Params. Are they all set correctly? For both the parent and the child?
Parent View. The code doesn't appear to be faulty from what I can see. So is the parent view being displayed correctly?
Visibility. Are both the parent and child View.VISIBLE?
EDIT
Sweet. Ok, when I'm debugging these things, I like to keep it simple at first. I would take the child view, set it's background color to purple (or a contrasting color from the parent). Then, for simplicity's sake, set it's layout params to match parent. Assuming the ParentView is a FrameLayout:
mChildView.setBackgroundColor(Color.CYAN);
mNewParentView.addView(mChildView,
new FrameLayout.LayoutParams(FrameLayout.LayoutParams.MATCH_PARENT, FrameLayout.LayoutParams.MATCH_PARENT, Gravity.CENTER));
Does it fill up and take over the parent?
In the intermediate steps, does it no longer have a parent when it's been removed?
Log.d("LOGTAG", mChildView.getParent().toString());
Does the new parent show that the child has been added?
Log.d("LOGTAG", mNewParentView.getChildCount()): // before and after
Is it being shown 'behind' the other views within the Parent?
mParentView.bringChildToFront(mChildView);
What may be the problem is that you are using getParent() to store oldParent. Compare for example:
if (view_to_move_around != null) {
ViewGroup oldParent = (ViewGroup) findViewById(R.id.old_parent);
if (view_to_move_around.getParent() == oldParent) {
oldParent.removeView(view_to_move_around);
}
} else {
// Initialise the View
}
newParent.addView(view_to_move_around)
Does this sound like what you're looking for? Let me know if this works.
I have an outer viewgroup (a ViewFlipper), and I want to programmatically put an inner view inside of it (a LinearLayout). I then want a reference to that inner view so I can do things with it later. So I'll have a line like this:
inflater.inflate(R.layout.my_linear_layout, myViewFlipper, true);
How can I get access to the inner view that I just inflated? The android docs for LayoutInflater claim that .inflate returns a reference to "the root View of the inflated hierarchy", but adds that "If root was supplied and attachToRoot is true, this is root", which I interpret to mean that in my case .inflate will return a reference to myViewFlipper.
try this
LinearLayout layout = (LinearLayout ) inflater.inflate(R.layout.my_linear_layout, null, false);
myViewFlipper.addView(layout);
You can also just search for that specific view?
LinearLayout layout = findViewById(R.id.the_id_of_the_linear_layout);
Or you can retrieve the first child of the ViewFlipper after inflating?
Anyway, inflate returns a View that you can use to search, find or do whatever you want with.
Short Story:
I have a layout "layout.xml", which gets replaced by another layout "success.xml" after a successful web request. Both layouts have an ImageView that provides the backgrounds to the layouts. These 2 backgrounds both need to be the same, and both are dependent on a user preference.
Longer Story: This all happens in a Fragmnet with an AsyncTask replacing the contentView with "success.xml" in onPostExecute after the web request. This happens as follows:
View view = getView();
view = null;
view = View.inflate(context, R.layout.success, null);
What I tried to do is give both ImageViews the following android:id="#+id/background_image" and then call
ImageView background = (ImageView)view.findViewById(R.id.background_image);
background.setImageResource(R.drawable.bg1);
This background-setting works for the initial view (layout.xml), but on trying to change to "success.xml", I get a NullPointException because background is null.
I've checked and the View's id is set to -1 while the original view's background_image id is set to something sensible and valid.
I've also tried setting the second view's background id like this: android:id="#id/background_image", i.e. without the '+', but still no luck.
The added complication is that it's not just 2 layouts, but about 5 that I need to do this for, so it would be really handy to recycle view id's.
Any help would be greatly appreciated.
Your code for replacing the fragment's view will not do what you want, the original view will remain the same as you change only a reference to that view and not the actual object.
To replace the view of the fragment with the new layout you could have another ViewGroup(for example a FrameLayout) in the basic layout (layout.xml) wrapping your current content(don't forget to give it an id) of layouts.xml(as I understand this is the basic layout). Then, when it's time to replace the layout you could simply do:
// remove the current content
((ViewGroup) getView().findViewById(R.id.yourWrapperLayout)).removeAllViews();
// add the new content
View.inflate(context, R.layout.success, ((ViewGroup) getView().findViewById(R.id.yourWrapperLayout)));
You could avoid adding an extra layout if, by any chance, all your five layouts have the same type for the root view(like a LinearLayout etc). In this case you would use the same code as above but you'll modify the other layouts file to use a merge tag. Also, you'll be looking for the id of the root in the layout.xml layout into which you'll add the content of the other files.
Then you could have the same ids, but you'll have to reinitialize any reference to the views(meaning that you'll have to search for the view again if you store a reference to the view(like a Button field in the fragment class)).
The LayoutInflater.inflate documentation isn't exactly clear to me about the purpose of the attachToRoot parameter.
attachToRoot: whether the inflated hierarchy should be attached to the root parameter? If false, root is only used to create the correct
subclass of LayoutParams for the root view in the XML.
Could someone please explain in more detail, specifically what the root view is, and maybe show an example of a change in behavior between true and false values?
NOW OR NOT NOW
The main difference between the "third" parameter attachToRoot being true or false is this.
When you put attachToRoot
true : add the child view to parent RIGHT NOW
false: add the child view to parent NOT NOW.
Add it later. `
When is that later?
That later is when you use eg parent.addView(childView)
A common misconception is, if attachToRoot parameter is false then the child view will not be added to parent. WRONG
In both cases, child view will be added to parentView. It is just a matter of time.
inflater.inflate(child,parent,false);
parent.addView(child);
is equivalent to
inflater.inflate(child,parent,true);
A BIG NO-NO
You should never pass attachToRoot as true when you are not responsible for adding the child view to the parent.
Eg When adding Fragment
public View onCreateView(LayoutInflater inflater,ViewGroup parent,Bundle bundle)
{
super.onCreateView(inflater,parent,bundle);
View view = inflater.inflate(R.layout.image_fragment,parent,false);
.....
return view;
}
if you pass third parameter as true you will get IllegalStateException because of this guy.
getSupportFragmentManager()
.beginTransaction()
.add(parent, childFragment)
.commit();
Since you have already added the child fragment in onCreateView() by mistake, calling add will tell you that child view is already added to the parent Hence IllegalStateException.
Here you are not responsible for adding childView, FragmentManager is responsible. So always pass false in this case.
NOTE: I have also read that parentView will not get childView touchEvents if attachToRoot is false. But I have not tested it though.
If set to true then when your layout is inflated it will be automatically added to the view hierarchy of the ViewGroup specified in the 2nd parameter as a child. For example if the root parameter was a LinearLayout then your inflated view will be automatically added as a child of that view.
If it is set to false then your layout will be inflated but won't be attached to any other layout (so it won't be drawn, receive touch events etc).
Seems like a lot of text in the responses but no code, that's why I decided to revive this old question with a code example, in several responses people mentioned:
If set to true then when your layout is inflated it will be automatically added to the view hierarchy of the ViewGroup specified in the 2nd parameter as a child.
What that actually means in code(what most programmers understand) is:
public class MyCustomLayout extends LinearLayout {
public MyCustomLayout(Context context) {
super(context);
// Inflate the view from the layout resource and pass it as child of mine (Notice I'm a LinearLayout class).
LayoutInflater.from(context).inflate(R.layout.child_view, this, true);
}
}
Notice that previous code is adding the layout R.layout.child_view as child of MyCustomLayout because of attachToRoot param is true and assigns the layout params of the parent exactly in the same way as if I would be using addView programmatically, or as if I did this in xml:
<LinearLayout>
<View.../>
...
</LinearLayout>
The following code explains the scenario when passing attachRoot as false:
LinearLayout linearLayout = new LinearLayout(context);
linearLayout.setLayoutParams(new LayoutParams(
LayoutParams.MATCH_PARENT, LayoutParams.WRAP_CONTENT));
linearLayout.setOrientation(LinearLayout.VERTICAL);
// Create a stand-alone view
View myView = LayoutInflater.from(context)
.inflate(R.layout.ownRootView, null, false);
linearLayout.addView(myView);
In the previous code you specify that you wanted myView to be it's own root object and do not attach it to any parent, later on we added it as part of the LinearLayout but for a moment it was a stand-alone (no parent) view.
Same thing happens with Fragments, you could add them to an already existing group and be part of it, or just pass the parameters:
inflater.inflate(R.layout.fragment, null, false);
To specify that it will be it's own root.
The documentation and the two previous answers should be enough, just some thoughts from me.
The inflate method is used to inflate layout files. With those inflated layouts you have to possibility to attach them directly to a parent ViewGroup or just inflate the view hierarchy from that layout file and work with it outside of the normal view hierarchy.
In the first case the attachToRoot parameter will have to be set to true(or much simple use the inflate method that takes a layout file and a parent root ViewGroup(non null)). In this case the View returned is simply the ViewGroup that was passed in the method, the ViewGroup to which the inflated view hierarchy will be added.
For the second option the returned View is the root ViewGroup from the layout file. If you remember our last discussion from the include-merge pair question this is one of the reasons for the merge's limitation(when a layout file with merge as root is inflated, you must supply a parent and attachedToRoot must be set to true). If you had a layout file with the root a merge tag and attachedToRoot was set to false then the inflate method will have nothing to return as merge doesn't have an equivalent.
Also, as the documentation says, the inflate version with attachToRoot set to false is important because you can create the view hierarchy with the correct LayoutParams from the parent. This is important in some cases, most notable with the children of AdapterView, a subclass of ViewGroup, for which the addView() methods set is not supported. I'm sure you recall using this line in the getView() method:
convertView = inflater.inflate(R.layout.row_layout, parent, false);
This line ensures that the inflated R.layout.row_layout file has the correct LayoutParams from the AdapterView subclass set on its root ViewGroup. If you wouldn't be doing this you could have some problems with the layout file if the root was a RelativeLayout. The TableLayout/TableRow also have some special and important LayoutParams and you should make sure the views in them have the correct LayoutParams.
I wrote this answer because even after going through several StackOverflow pages I wasn't able to clearly grasp what attachToRoot meant. Below is inflate() method in the LayoutInflater class.
View inflate (int resource, ViewGroup root, boolean attachToRoot)
Take a look at activity_main.xml file, button.xml layout and the MainActivity.java file I created.
activity_main.xml
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:id="#+id/root"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">
</LinearLayout>
button.xml
<Button xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="wrap_content" />
MainActivity.java
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
LayoutInflater inflater = getLayoutInflater();
LinearLayout root = (LinearLayout) findViewById(R.id.root);
View view = inflater.inflate(R.layout.button, root, false);
}
When we run the code, we won't see the button in the layout. This is because our button layout is not added into the main activity layout since attachToRoot is set to false.
LinearLayout has an addView(View view) method which can be used to add Views to LinearLayout. This will add the button layout into the main activity layout, and make the button visible when you run the code.
root.addView(view);
Let's remove the previous line, and see what happens when we set attachToRoot as true.
View view = inflater.inflate(R.layout.button, root, true);
Again we see that the button layout is visible. This is because attachToRoot directly attaches the inflated layout to the parent specified. Which in this case is root LinearLayout. Here we don't have to add the views manually like we did in the previous case with addView(View view) method.
Why are people getting IllegalStateException when setting attachToRoot as true for a Fragment.
This is because for a fragment you have already specified where to place your fragment layout in your activity file.
FragmentManager fragmentManager = getSupportFragmentManager();
fragmentManager.beginTransaction()
.add(R.id.root, fragment)
.commit();
The add(int parent, Fragment fragment) adds the fragment which has it's layout to the parent layout. If we set attachToRoot as true, you will get IllegalStateException: The specified child already has a parent. Since fragment layout is already added to the parent layout in the add() method.
You should always pass false for attachToRoot when you're inflating Fragments. It is the FragmentManager’s job to add, remove and replace Fragments.
Back to my example. What if we do both.
View view = inflater.inflate(R.layout.button, root, true);
root.addView(view);
In the first line, LayoutInflater attaches the button layout to the root layout and returns a View object which holds the same button layout. In the second line, we add the same View object to the parent root layout. This results in the same IllegalStateException we saw with Fragments (The specified child already has a parent).
Keep in mind that there is another overloaded inflate() method, which sets attachToRoot as true by default.
View inflate (int resource, ViewGroup root)
I myself was also confused about what was the real purpose of attachToRoot in inflate method. After a bit of UI study, I finally got the answer:
parent:
in this case is the widget/layout that is surrounding the view objects that you want to inflate using findViewById().
attachToRoot:
attaches the views to their parent (includes them in the parent hierarchy), so any touch event that the views recieve will also be transfered to parent view. Now it's upto the parent whether it wants to entertain those events or ignore them. if set to false, they are not added as direct children of the parent and the parent doesn't recieve any touch events from the views.
Hope this clears the confusion
There is a lot of confusion on this topic due to the documentation for the inflate() method.
In general, if attachToRoot is set to true, then the layout file specified in the first parameter is inflated and attached to the ViewGroup specified in the second parameter at that moment in time. When attachToRoot is false, the layout file from the first parameter is inflated and returned as a View and any View attachment happens at some other time.
This probably doesn't mean much unless you see a lot of examples. When calling LayoutInflater.inflate() inside of the onCreateView method of a Fragment, you will want to pass in false for attachToRoot because the Activity associated with that Fragment is actually responsible for adding that Fragment's view. If you are manually inflating and adding a View to another View at some later point in time, such as with the addView() method, you will want to pass in false for attachToRoot because the attachment comes at a later point in time.
You can read about several other unique examples concerning Dialogs and custom Views on a blog post I wrote about this very topic.
https://www.bignerdranch.com/blog/understanding-androids-layoutinflater-inflate/
attachToRoot set to true means the inflatedView will be added to the parent view's hierarchy. Thus can possibly be "seen" and sense touch events (or any other UI operations) by users. Otherwise, it is just been created, not been added to any view hierarchy and thus cannot be seen or handle touch events.
For iOS developers new to Android, attachToRoot set to true means you call this method:
[parent addSubview:inflatedView];
If going further you might ask: Why should I pass parent view if I set attachToRoot to false? It is because the root element in your XML tree needs the parent view to calculate some LayoutParams (like match parent).
When you define the parent the attachToRoot determines whether you want the inflater to actually attach it to the parent or not. In some cases this causes problems, like in a ListAdapter it will cause an exception because the list tries to add the view to the list but it says it's already attached. In other cased where you're just inflating the view yourself to add to an Activity it could be handy and save you a line of code.
For example we have an ImageView , a LinearLayout and a RelativeLayout. LinearLayout is the child of RelativeLayout.
the View Hierarchy will be.
RelativeLayout
------->LinearLayout
and we have a separate layout file for ImageView
image_view_layout.xml
Attach to root:
//here container is the LinearLayout
View v = Inflater.Inflate(R.layout.image_view_layout,container,true);
Here v contains the reference of the container layout i.e the
LinearLayout.and if you want to set the parameters like setImageResource(R.drawable.np); of ImageView you will have to find it by the reference of parent i.e view.findById()
Parent of v will be the FrameLayout.
LayoutParams will be of FrameLayout.
Not attach to root:
//here container is the LinearLayout
View v = Inflater.Inflate(R.layout.image_view_layout,container,false);
Here v contains the no reference container layout but direct
reference to the ImageView that is inflated so you can set its
parameters like view.setImageResource(R.drawable.np); without
refereing like findViewById. But container is specified so that
ImageView gets the LayoutParams of the container so you can say
that the reference of container is just for LayoutParams nothing
else.
so in particular case Parent will be null.
LayoutParams will be of LinearLayout.
attachToRoot Set to true:
If attachToRoot is set to true, then the layout file specified in the first parameter is inflated and attached to the ViewGroup specified in the second parameter.
Imagine we specified a button in an XML layout file with its layout width and layout height set to match_parent.
<Button xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="#+id/custom_button">
</Button>
We now want to programmatically add this Button to a LinearLayout inside of a Fragment or Activity. If our LinearLayout is already a member variable, mLinearLayout, we can simply add the button with the following:
inflater.inflate(R.layout.custom_button, mLinearLayout, true);
We specified that we want to inflate the Button from its layout resource file; we then tell the LayoutInflater that we want to attach it to mLinearLayout. Our layout parameters are honored because we know the Button gets added to a LinearLayout. The Button’s layout params type should be LinearLayout.LayoutParams.
attachToRoot Set to false (not required to use false)
If attachToRoot is set to false, then the layout file specified in the first parameter is inflated and not attached to the ViewGroup specified in the second parameter but that inflated view acquires parent's LayoutParams which enables that view to fit correctly in the parent.
Let’s take a look at when you would want to set attachToRoot to false. In this scenario, the View specified in the first parameter of inflate() is not attached to the ViewGroup in the second parameter at this point in time.
Recall our Button example from earlier, where we want to attach a custom Button from a layout file to mLinearLayout. We can still attach our Button to mLinearLayout by passing in false for attachToRoot—we just manually add it ourselves afterward.
Button button = (Button) inflater.inflate(R.layout.custom_button, mLinearLayout, false);
mLinearLayout.addView(button);
These two lines of code are equivalent to what we wrote earlier in one line of code when we passed in true for attachToRoot. By passing in false, we say that we do not want to attach our View to the root ViewGroup just yet. We are saying that it will happen at some other point in time. In this example, the other point in time is simply the addView() method used immediately below inflation.
The false attachToRoot example requires a bit more work when we manually add the View to a ViewGroup.
attachToRoot Set to false(false is Required)
When inflating and returning a Fragment’s View in onCreateView(), be sure to pass in false for attachToRoot. If you pass in true, you will get an IllegalStateException because the specified child already has a parent. You should have specified where your Fragment’s view will be placed back in your Activity. It is the FragmentManager’s job to add, remove and replace Fragments.
FragmentManager fragmentManager = getSupportFragmentManager();
Fragment fragment = fragmentManager.findFragmentById(R.id.root_viewGroup);
if (fragment == null) {
fragment = new MainFragment();
fragmentManager.beginTransaction()
.add(R.id.root_viewGroup, fragment)
.commit();
}
The root_viewGroup container that will hold your Fragment in your Activity is the ViewGroup parameter given to you in onCreateView() in your Fragment. It’s also the ViewGroup you pass into LayoutInflater.inflate(). The FragmentManager will handle attaching your Fragment’s View to this ViewGroup, however. You do not want to attach it twice. Set attachToRoot to false.
public View onCreateView(LayoutInflater inflater, ViewGroup parentViewGroup, Bundle savedInstanceState) {
View view = inflater.inflate(R.layout.fragment_layout, parentViewGroup, false);
…
return view;
}
Why are we given our Fragment’s parent ViewGroup in the first place if we don’t want to attach it in onCreateView()? Why does the inflate() method request a root ViewGroup?
It turns out that even when we are not immediately adding our newly inflated View to its parent ViewGroup, we should still use the parent’s LayoutParams in order for the new View to determine its size and position whenever it is eventually attached.
Link: https://youtu.be/1Y0LlmTCOkM?t=409
Just sharing some points that i encountered while working on this topic,
In addition to the accepted answer i want to some points which could be of some help.
So, when i used attachToRoot as true, the view which was returned was of type ViewGroup i.e. parent's root ViewGroup which was passed as parameter for the inflate(layoutResource,ViewGroup,attachToRoot) method, not of type the layout which was passed but on attachToRoot as false we get the function return type of that layoutResource's root ViewGroup.
Let me explain with an example:
If we have a LinearLayout as the root layout and then we want to add TextView in it through inflate function.
then on using attachToRoot as true inflate function returns a View of type LinearLayout
while on using attachToRoot as false inflate function returns a View of type TextView
Hope this finding would be of some help...