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 > > 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? > > 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... -- 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
