It's hard to keep them unique. - One possibility is to make aapt (which is what compile them into R.java and packages them into the apk) be given a different starting value for each library. The problem is that you can have any combo of library so which starting point do you use when compiling your library when you don't know what's going to use it?
- Another possibility is to have aapt package all the libraries and the main project in a single pass, so that it knows how many libraries there are and automatically set starting values. Well, in that case you need to store the Ids in the main project anyway, because if you compile the same library in the scopes of 2 different projects, then you'll get two different R.java for the same library, which means the library must be compiled in the scope of the project that uses it... which is what we do without bothering with different starting values per library :) On Wed, May 26, 2010 at 1:58 PM, Mark Carter <[email protected]> wrote: > Thank you for explaining. > With regards to the conflicting resource IDs, couldn't you just make > whatever assigns those IDs keep them unique across different projects? > > On 26 May 2010 22:46, Xavier Ducrohet <[email protected]> wrote: >> >> 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 > > -- > 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
