Fragment onCreateView inflate notes, fragmentinflate

Fragment onCreateView inflate notes, fragmentinflate

I have been using Fragment for a long time. Today I suddenly found that the sub-Fragment is full screen, but the width is only a little bit. In fact, the essence of this problem is the use of the inflate method. I have studied it before, but I have left a record, which is exposed in fragment usage. Intuition tells me which one has a problem, and it will soon be locked to onCreateView.
In onCreateView, we generally have two writing methods: Method 1:

        @Override    public View onCreateView(LayoutInflater inflater, ViewGroup container,            Bundle savedInstanceState) {        // TODO Auto-generated method stub        View root = inflater.inflate(layoutId(), container, false);        return root;    }

Method 2

    @Override    public View onCreateView(LayoutInflater inflater, ViewGroup container,            Bundle savedInstanceState) {        // TODO Auto-generated method stub        View root = inflater.inflate(layoutId(), null);        return root;    }   

Both of them are acceptable, but if the second type is used, the parameter information of the parent layout will not be inherited. See the following document:

    /**     * Inflate a new view hierarchy from the specified xml resource. Throws     * {@link InflateException} if there is an error.     *      * @param resource ID for an XML layout resource to load (e.g.,     *        <code>R.layout.main_page</code>)     * @param root Optional view to be the parent of the generated hierarchy.     * @return The root View of the inflated hierarchy. If root was supplied,     *         this is the root View; otherwise it is the root of the inflated     *         XML file.     */    public View inflate(int resource, ViewGroup root) {        return inflate(resource, root, root != null);    }

    /**     * Inflate a new view hierarchy from the specified xml resource. Throws     * {@link InflateException} if there is an error.     *      * @param resource ID for an XML layout resource to load (e.g.,     *        <code>R.layout.main_page</code>)     * @param root Optional view to be the parent of the generated hierarchy (if     *        <em>attachToRoot</em> is true), or else simply an object that     *        provides a set of LayoutParams values for root of the returned     *        hierarchy (if <em>attachToRoot</em> is false.)     * @param 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.     * @return 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.     */    public View inflate(int resource, ViewGroup root, boolean attachToRoot) {        final Resources res = getContext().getResources();        if (DEBUG) {            Log.d(TAG, "INFLATING from resource: \"" + res.getResourceName(resource) + "\" ("                    + Integer.toHexString(resource) + ")");        }        final XmlResourceParser parser = res.getLayout(resource);        try {            return inflate(parser, root, attachToRoot);        } finally {            parser.close();        }    }

Method 2 finally calls method 1, that is, inflate (int resource, ViewGroup root, boolean attachToRoot. if the root is not empty and the value of attachToRoot is false, the document clearly states: If false, root is only used to create the correct subclass of LayoutParams for the root view in the XML, that is, root is only used to create the parameter information of the parent layout. If it is true, it is added to the parent layout. Because manual add is required when we control fragment, attachToRoot must be false here.

In turn, if method 2 is used, the root must pass null. In this case, the child view will not get the layout information of the parent view, and a pile of match_parent in the Child view will be useless.

Summary: in the case of 90%, we must use method 1 to use fragment. For example, if you do not need to obtain parent layout parameter information when creating dialog fragment, you can use method 2.

Supplement: The layoutId () in the code above is a virtual function used to implement it in the subclass. Only return R. layout.*You do not have to rewrite onCreateView for each fragment. In onViewCreated, each control is instantiated based on the input parameter root.