Creating Android JARs is fairly easy...so long as all you want to do is ship Java code. If your Java code needs resources or assets, or offers up activities or services, then you have to ship a JAR plus a whole bunch of other stuff. And the person reusing your JAR would need to know about all that other stuff, find it, download it into the right spots, etc. The only way that is somewhat convenient for the developers is to package this stuff into separate APKs...which is inconvenient for the users.
IMHO, that's one of the reasons why we don't have a robust collection of third-party widgets or other libraries. There are few recipes for creating such things, no standards or conventions for how to consume them, and no home for them to live. At least, I am not aware of much in this area -- please correct me if I've missed something. I've been working on a solution for all of that, or as good of a solution as I can create given some of the peculiarities of Android's build tools. Before I invest much more time, though, I need to know if anyone really cares. ---------------- Suppose you found out about...say...a calendar widget you wanted for integration in your app. You might have found it from a Web-based catalog of components, or from a search engine query, or a StackOverflow answer, or whatever. To download that calendar widget, you would run: parcel install <name> where <name> is the unique identifier for this widget. That would download the widget to your development machine, plus download any dependent libraries. To use that widget in one of your Android projects, you would run: parcel inject <name> from the project base directory. This would: -- copy the JAR file(s) into libs/ -- copy the resource(s) into res/ -- merge in key elements (e.g., activities) into AndroidManifest.xml -- copy documentation and other stuff into parcels/<name> -- do all of the above for all dependencies as well If you write a calendar widget and want to make a parcel for others to reuse, there would be: parcel package <name> ... where you specify the parcel to create and all the stuff that should go in it (JARs, resources, source code, documentation, etc.). You could wrap this up in an Ant task or Maven plugin or Eclipse, um, thingy, if you wished to integrate this as part of a build process. There's more to it, but this should give you the feel for what I have in mind. It is modeled loosely after RubyGems and Rails vendor plugins, two of the more successful examples of this pattern in use today. ---------------- If this is something you would like to see, please reply to this message, or tweet me (@commonsguy), to let me know of your interest. If I release this, I'll be committing a fair chunk of time to helping to maintain it, and I don't want to make that commitment until I have a sense that enough people will care. I am, of course, certainly open to other ideas, suggestions, Googly input, etc. :-) Thanks in advance! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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.
