Jargon wrote: > We are investigating the possibilities to package & deploy platform UI > extensions which can contain both Java code and resources - which then > can be (re-)used by applications using <uses-library> tag in the > AndroidManifest.xml.
You and me both, though I'm not trying to use <uses-library>. > One solution which has been discussed was to use the aapt -x option > together with the new --custom-package option introduced in November > to generate unique resource identifiers for the shared resource > package. That's interesting -- I had not noticed --custom-package before. I will need to do some experiments to see if this helps with the solution I'm working on. > Then, just as the <uses-library> information in the manifest file > would bootstrap the class loader with the listed extension packages, > it would add these packages to the asset manager as well - allowing > the asset manager to locate and load the extension resources. (This > would require a platform extension.) I'm trying to avoid anything that requires modifying the SDK, and I agree that overloading <uses-library> this way would require such modifications AFAIK. > So, my question is really if this is a way forward - using the 8 > package bits in the resource identifiers? What are the "8 package bits"? > This solution would probably > work initially for one vendor since the allocation of unique package > identifiers would be an internal issue, but if extension packages > where to be exchanged within the android community there would be a > high risk of packages using the same identifiers. The issue of identifier collisions is a well-understood one for those who have done development before with reusable components or modular operating systems. Everything from Linux's apt and yum to Ruby gems requires unique identifiers. So long as there are a handful of popular repositories, "first one in wins" should suffice there. Hence, I am not that worried about that aspect of the problem too much. Whoever comes up with a component packaging system just needs to also run a repository. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.4 Available! -- 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 To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
