inflater.inflate(R.layout.fragmenta , container , false);
We use this line of code for inflating. Despite read documentary , i didn't understand what is the second and third parameters function is ? What is the root in this situation and what happen if i change third to true ?
In your layout XML file some of the attributes relate to the parent container. Anything that starts with layout_*. The container, or parent in some cases, is needed to resolve those values. You can see this with things like layout_margin. If you don't give the inflater a parent you won't have any margins. But if you wrap your layout in another container like a frame layout it works. That's because it's able to resolve layout_margin using the frame layout. I'm not completely sure about the attach to parent boolean. I always get Exceptions when I set it to true.
Layout Inflater
The video should give you a good explanation of what is done and why it is done.
Related
I am using the scrolling activity generated by Android Studio. So something like this:
It uses an #include tag in the XML to load the content of the activity.
I need to change the content inside this NestedScrollView to something else. So I have been using this:
LayoutInflater inflater =
(LayoutInflater) getSystemService(Context.LAYOUT_INFLATER_SERVICE);
progressContent = inflater.inflate(R.layout.content_progress, null);
scrollView.removeView(normalContent);
scrollView.addView(progressContent);
And it works, but it doesn't use the ConstraintLayout of the progressContent correctly, it ignored all the bias values and only keeps hard set margins and paddings.
In this question, people suggested to use ´setContentView` but since I only have to change the inner content, not the whole layout, it's not the right solution:
How to set layout dynamically in android
In this one it was suggested to use ViewStubs instead of #include:
How can I programmatically include layout in Android?
But this only resulted in a completely broken CollapsingToolbarLayout and the layout parameters of the second view got discarded regardless.
What is the correct way of doing this?
I've read this answer : https://stackoverflow.com/a/5027921/1364174
And wonder why depending on the root parameter inflate method changes its behavior such drastically creating confusion.
According to that answer this code:
view = LayoutInflater.from(getBaseContext()).inflate(R.layout.smallred, null);
parent.addView(view);
Will create will create view specified in smallred.xml completely ignoring the properties of tags replacing them with some mysterious defaults values.
But this code will respect the properties from smallred.xml
view = LayoutInflater.from(getBaseContext()).inflate(R.layout.smallred, parent, false);
parent.addView(view);
Why is that ? Why we need to specify root/parent to which we later insert our view to, nflate" method?
Why is that necessary ? Why if we wouldn't we won't get the properties from .xml file ?
Probably because attributes are read only when you are actually inflating the view, so once you inflate it without providing the parent you will be missing information inside the inflated view. Then it doesn't matter if you add it to a parent, the data isn't there so the layout won't be as you expected it to be.
The layoutinflater doesn't know about your parent when he's inflating your view. So it doesn't even know its class. If you notice, every layout has its own LayoutParams class inside it, and you have to tell the layoutinflater which one it has to use or they will be simply discarded.
Say you have a TextView that you made in an xml file. I am wondering if it is possible to copy this view's Layout Parameters programmatically instead of having to programmatically write them all out again. Or if you could just create a new TextView and make it the same as the original one and then attach it to a new view that will be added.
I tried the latter and ran into the error that said:
08-09 22:04:55.253: E/AndroidRuntime(1848): Caused by: java.lang.IllegalStateException: The specified child already has a parent. You must call removeView() on the child's parent first.
But this error would persist even after I had tried removing them from the initial view. Any ideas? Or is this just completely unfeasible and dumb.
You can always inflate a new View from the same xml. Adapter classes do this all the time, for example in ListViews the adapter will inflate all if it's rows from the same xml resource.
Of course you can get layout params for that specular TextView with;
TextView myTextView=(TextView) findViewById(<your-TextView's-id>);
ViewGroup.LayoutParams layPar=myTextView.getLayoutParams();
and you can copy another one from this and add it to new view like this;
newView.addView(newTextView);
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)).
I have bookmark ImageButton with ALIGN_WITH_PARENT set to true in XML.
If I programatically do (I want to remove that rule)
RelativeLayout.LayoutParams params = (LayoutParams) bookmark.getLayoutParams();
params.addRule(RelativeLayout.ALIGN_PARENT_RIGHT, 0);
bookmark.setLayoutParams(params);
The rule just doesn't apply (in my layout I can see that rule is still active) -> layout isn't good. If I manually do it (some sort of "simulation", set ALIGN WITH PARENT to false) in my Layout Editor, my layout is fine which leads to this code up there. Something is wrong.
What?
(I believe temporary) Solution is to wrap up that ImageButton in one dummy RelativeLayout and then take the params of that dummy layout and add or remove rules. That way it's working just fine.
Insead of calling setLayoutParams(), try to use requestLayout() method:
bookmark.requestLayout();
From API docs:
Call this when something has changed which has invalidated the layout of this view. This will schedule a layout pass of the view tree.
simply call removeRule() function on params.
for example,
params.removeRule(RelativeLayout.CENTER_IN_PARENT);