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?
- 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")
- 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?
- What design pattern does it follow(if there is one)?
- 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.
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).
Biggest advantage is in Localization and Providing alternate resources for different screen sizes.
e.g you can have a String resource R.string.myname
this could be a defined in english in /values-en/strings.xml
and in spanish in /values-es/strings.xml
System will take care or picking up the right file depending on the locale you just need to use @string/myname
in your layout file or R.string.myname
in your code.
Similarly you could have two layout files for portrait and landscape defined in
res/layout/mylayout.xml
res/layout-land/mylayout.xml
In your code you will just specify R.layout.mylayout to inflate the layout. Resource manager
picks up the file in layout-land if the device is in landscape mode.
Doing this manually would be a nightmare -- hence the need for R file
The comparison feels somewhat a little bit (actually) weird, because you compare two mechanism based on the fact that they use named things for doing stuff. For resource loading, e.g., have a look at how resource handling is done in the .Net
world.
It provides for compile-time checking if the resource is available. Because if it not, there will not be a static inside R.java
that points to it. In the Spring example, how can you be sure there is a bean called beanId
? It does not provide for checking if it is the right type of resource, though.
Why is this not loose? As long as the new resource has the same name, it will generate the same static constant. In Spring, you would have to use the same bean name.
Design Pattern? None. It just adds one level of indirection by naming the resources and then refer to them only by name, not by directly loading them from their true location.
Actually, the resources are injected, because resource loading must cope with localization. See here for how Android does stuff; in the .Net
world, additional cultures are packed into satelite assemblies; the resource manager will load the right one based on the current culture.
It also contains access to resources - such as id, drawables, layouts, strings, arrays, and basically anything you can declare in resources.