I'm sure this would be very useful to some/many. But, personally, I'm specifically interested in sharing in-house resources-based jars between my own apps.
Currently I'm resorting to a prehistoric copy-paste approach! On Mar 29, 4:19 pm, Mark Murphy <mmur...@commonsware.com> wrote: > 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.
