On Sat, May 22, 2010 at 2:48 PM, Mark Carter <[email protected]> wrote: > On May 22, 10:12 pm, Xavier Ducrohet <[email protected]> wrote: >> The manifest for the library is not used besides looking at the >> package name for the library. > > So, for now, the packageName is the only important thing in the > library manifest? > >> The question is what happens when a project depends on libraries A & B >> which both depend on library C. What's the library priority order? A, >> B, C or A, C, B? > > Why didn't you just use fully qualified resources when referring to > library resources? > > So, in XML that would be "@mylibrary:string/mystring" and in Java > com.mycompany.mylibrary.R.String.mystring etc
This would require platform changes, which means it would only have worked on 2.2. We wanted to make this a build change only in order to support 1.5+ (the 1.5/1.6/2.1 SDK components were updated only to update the build system) >> > 4. If an app references both resources and code in a library project, >> > then that library project needs to be added as both a library and a >> > project in the app's build path (in eclipse at least) - why is this? >> >> hmm no you should not have too. >> Adding the library as a project dependence (in project properties >> under Android) should bring the source code of the library into the >> main project. > > It seems that when I was adding the library before, it wasn't being > added properly. I set it as described in the docs but for some reason > it wasn't showing up as a library under the project. > > Now, I've recreated all the projects and this time the library shows > up as a child "node" of the MyApp project. So it all seems to work. I > didn't do anything different from before, but maybe starting from a > clean slate made a difference... > > I think the bug mentioned in my second post was due to (additionally) > specifying the library as a project in the build path of MyApp. > Something was expecting MyLibrary.apk to exist because of that (and > because MyLibrary is an Android project). Just a guess. > > Now that I don't need to specify the library in the build path, this > problem is gone. > > If this is right, maybe it would be good to stop the same project from > being added in both places? yeah we should add a test there. >> > 5. I'm considering subclassing library project activities/services in >> > my app project. Is there any reason not to do this? >> >> Since the library project is compiled inside the app project, there's >> no reason this won't work. > > Consider this pro & lite projects scenario: > > Pro-specific activities go in the pro project. > Common activities go in the library. > > But what about common activities that are slightly different in pro > versus lite? Could be tricky to inject pro-specific behaviour into > those common activities (because of the way activities are > instantiated). > > It seems it might be simpler to just subclass such activities... Yes, which is why I said it should work :) xav -- 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
