Why Devs Should Avoid ‘Null’ when Inflating Layouts
We’ve all done it at one point or another. You are hammering out some code and need one aspect of a method call to work so you just put null in for the rest of the parameters instead of actually researching how they work. I’ve actually done the very thing Dave Smith writes of in his article about inflating layouts. The second argument in a LayoutInflater inflate method calls for ‘ViewGroup root.’ I just slap ‘null’ in there and go about my business, none the wiser. There’s nothing wrong with that; it pulls the XML file passed as the first parameter into your layout so that it can be displayed on the screen. You could go years without having a real problem with it. But when it does it bite you at some point down the road, you’re going to pay a big time penalty trying to figure out what is going wrong.
Dave did a great job writing his article explaining how a LayoutInflater works. The reason the inflater is looking for a ViewGroup is to inherit any styling that may have been set at a higher lever. He shows an example of this using a ListView that should have a fixed height specified by the theme. If you specify null, it has no context from which to inherit the values and results in the smallest height possible. He goes on to assume that the developer would then create a second XML specification to fix the problem, and I think he’s spot on with that prediction. This breaks the concept of themes and makes the code much harder to maintain. He does mention an exception when inflating for an AlertDiaog, but this is a moot point because the inflater will basically ignore the ViewGroup parameter when specified for a dialog.