This is a pretty interesting idea. It's hard to think of where this would be useful, but I can imagine some people finding a use for it, but you could spend a great deal of time trying to develop and maintain this and it would have slow take- up, only after some fairly common "parcels" start to get used by a majority will it gain any ground in the community.
I guess the thing for me is if I wanted a library or tool for (i.e. a calendar widget) I would probably want to have the resources and insert them myself, that way I can customise it (make it look unique to my app, users don't want 10x the same looking widget with different text), use my own naming conventions for classes and activities (in source and manifest.xml) etc this way I will be aware of what's happened and where. Would you have any idea of how to keep these parcel's up to date? It's a great idea, but not sure how successful it would be, and whether it would be worth the amount of time you might spend on it. I kind of feel like this is a lower version of an open intent where a user could install a calendar widget and then other apps can hook into the application to display information through that widget. While it might be a pain to the user initially, I think most would see it as an extra and therefore have to make a little extra effort to go download the necessary applications, which I don't think many would mind. Have a look a twicca, they have their main application and then a set of plug-in applications which give some extra functionality to their main app. Keep us posted on what you decide to do. Cheers, Matt On Mar 29, 3: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.
