Home/ Questions/Q 7739305
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T08:29:22+00:00

In android R.java is used to provide access to resources defined in XML files.

  • 0

In android R.java is used to provide access to resources defined in XML files.
To access the resource we need to invoke findViewById() method passing in the id of the resource to be fetched.

This is similar to Spring where beans are defined in a XML context and are fetched by using application context. context.getBean("beanId")

This provides loose coupling since the beans are defined externally and could be changed without making modifications to the code.

This has me confused. Though what Android does looks similar to spring, what advantage does it offer?

  1. What is the point of having an intermediate R.java anyway? Couldn’t we just acquire resources directly from XML by use of a resource
    reader/application context. e.g. findViewById("resourceId")
  2. There isn’t any loose coupling. Since references in R.java get auto-generated how could one delete a resource and put in a new one?
  3. What design pattern does it follow(if there is one)?
  4. Wouldn’t it be better to have resources injected using IOC (like Roboguice)? Why did then google decide to give us such
    a wierd way of working with resources?

Pardon my ignorance. I’m a newbie Java developer trying too many things at once. 🙂
Thanks for all the feedback.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    android.R.java is not just where XML ids are stored. It also contains access to resources – such as drawables, layouts, strings, arrays, and basically anything you can declare in resources.

    Personally I find that it is useful when using Eclipse. I can simply type findViewById(R.id. and Eclipse will show a tooltip with a list of options to choose from.

    However at a platform level, I would say that the hardcoded id variables help prevent errors when using Strings to identify resources — something that can be debuggable while programming (or during compilation, rather than runtime).

    • 0