It's essential because It's impossible to have each library handle its resources independently.
Currently there's no way to have each library packages its resources (and give them resources IDs) in a way that doesn't conflict with other resources. This means if we compile resources for 2 libraries, the first layout in R.layout in both libraries will have the same ID. Of course when we package the resources together for the apk, then the ID for resources coming from the libraries will have a different ID than if they were packaged separately. This means the R class must be created from *all* the resources, and the library code must be compiled with the final R class. Now, we could implement resource namespace or multiple res packages inside an apk so that libraries can manage their resources separately. The big issue here is that it's a platform change which means it won't work on older platforms. Our goal was to support 1.5+ so implementing them purely at the build level was chosen. We could also have made the library code access the R.*.* values through reflection. I would have been a bit slower, but through a cache mechanism this could work. This would also allow people to distribute library binaries. I feel this is less useful though, but we may offer this as an option at some point. On Wed, May 26, 2010 at 11:58 AM, Mark Carter <[email protected]> wrote: > On 26 May 2010 20:33, Xavier Ducrohet <[email protected]> wrote: >> >> The problem is not so much generating the R class, it's making sure >> the library project is compiled with this "composite" R class made of >> all the projects (main + libs). > > Is it essential for the library project to be compiled with the composite R > class? > At each level in the library hierarchy, the R class would only include the > resources of its own project and any descendant libraries. You could enforce > that no two projects in the hierarchy define the same resource (otherwise > give a compiler error). > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- Xavier Ducrohet Android SDK Tech Lead Google Inc. Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
