It wouldn't need to know about anything else specifically in the app project. When asked to generate ids for some library it just needs to make sure it doesn't use any IDs given before.
On 26 May 2010 23:34, Xavier Ducrohet <[email protected]> wrote: > well if you let aapt work it out for itself it will need to know about > the other libraries used by the project. So you're back to exporting > the library in the scope of the main project. > > On Wed, May 26, 2010 at 2:13 PM, Mark Carter <[email protected]> > wrote: > > With regards to the first possibility... > > Rather than giving the aapt a starting value why not let it work it out > for > > itself? Nothing else is generating those ids, so it can be sure that it > > doesn't give the same id to a different project. > > This, of course, assumes that the aapt has some way to persist this data > > between calls - which I'm sure there must be. > > On 26 May 2010 23:04, Xavier Ducrohet <[email protected]> wrote: > >> > >> 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]<android-developers%[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]<android-developers%[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]<android-developers%[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]<android-developers%[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]<android-developers%[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]<android-developers%[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
