0

From what I have understood in Stackoverflow till now...all that the instance of LayoutInflater does is accepts the XML layout file to be inflated (probably using some internal XML parser and iteration logic to instantiate view from the tree-like structure set it's attributes accordingly) and as well as the parent to which the tree should be attached along with an optional attachToRoot parameter. This means that the inflater itself doesn't hold any unique information from wherever it gets instantiated. So why isn't the functionality of creating/inflating a view available in the form of a simple static method that just creates the view with the parameters passed to it? Is it that I am missing out on something?

Also, I am unable to understand the concept of attachToRoot... The code in this answer passes attachToRoot as false and states that the layout wouldn't directly attach the view yet? Does it mean that if we would have passed true, we wouldn't have needed manually add that view? (Just as a side question again, would the behavior of the app be different if we would have changed the properties after adding it) https://stackoverflow.com/a/41500409/10104608

David Wasser
  • 93,459
  • 16
  • 209
  • 274
Henlo Wald
  • 37
  • 6

1 Answers1

0

LayoutInflater uses resources (XML layout files, string resources, dimension resources, etc.) to do its job. Resource files are not unique as they can be device-dependent, language-dependent, etc. Therefore, LayoutInflater needs a Context to ensure that it has access to the resource files and that it can determine which of the many possible resource files to use for a given resource reference. This requirement for a Context is why you need a LayoutInflater instance (as opposed to using a static method call).

Regarding your question about "attach to root": You can inflate a View and add it to the View hierarchy manually, or your can let LayoutInflater do it automatically. This is the purpose of the "attach to root" parameter.

I haven't looked at the code for LayoutInflater but I would not be surprised if some resource data was cached in the instance, as there is probably only one LayoutInflater instance created for each Context and this instance is probably shared/reused.

David Wasser
  • 93,459
  • 16
  • 209
  • 274
  • Can an app have multiple contexts? If not, then why aren't such things static by design since they can anyways be re-used by the same app? – Henlo Wald Jul 11 '21 at 22:22
  • Yes, of course. The device orientation can change while the app is running. User's can change language, Themes can be set dynamically while the app is running. All of this has significant impact on the Context. – David Wasser Jul 12 '21 at 07:21
  • So is the entire context re-instantiated and replaced then? – Henlo Wald Jul 12 '21 at 18:56
  • There are multiple `Context`s. There is an application `Context` that is created once for the app and it can be modified while the app is running. Each `Service` and `Activity` has a `Context` and these can also be modified while the app is running. Not exactly sure where you are going with this line of questioning... – David Wasser Jul 12 '21 at 20:03