[android-developers] Re: Reusable Android library packaging: interest?
We are very aware of the need for this use case (in-house sharing of code/resources), and are working on something. That is good to hear! OpenIntents might be a good place to host a repository of public widgets, as there is already a list of open intents and reusable libraries. I support Mark's effort! Friedger --- www.openintents.org www.droidcon.com -- 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
Re: [android-developers] Re: Reusable Android library packaging: interest?
On Mon, Mar 29, 2010 at 9:21 AM, westmeadboy westmead...@yahoo.co.uk wrote: 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! We are very aware of the need for this use case (in-house sharing of code/resources), and are working on something. Xav -- Xavier Ducrohet Android SDK Tech Lead Google Inc. Please do not send me questions directly. Thanks! -- 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, reply using remove me as the subject.
[android-developers] Re: Reusable Android library packaging: interest?
I've been holding off on replying to this only because I haven't fully collected my thoughts. I hope to write up my recommendations for build approaches, especially for free/paid apps, before really wrapping my mind around it. But since that's taking me a while, I thought I should chime in, yes, I'm interested. Quite. But one thought is that making this be a command may not be the best approach for integration into build systems. I'm thinking that packaging it as an ant macro in an antlib may be a better approach, with the underlying technology being a .zip file with the various pieces. Then, if you feel the need for a command, you could create an ant script, and simple shell scripts to invoke it. This would leverage Ant's facilities (.zip files, file operations, xslt to update the manifest, etc), give you platform independence, and not require any software installation other than the antlib, since people already need ant (even if they don't know it). It's not that I'm a huge fan of ant. But it's adequate, and already a part of the tool mix. And I see the primary endpoint being good integration with building, and ant is a key part of that for most of us. It looks like this should mostly integrate cleanly with the build approach I'm about to blog about. My approach, for production builds, produces pristine clones of your hierarchy, so injecting into this won't interfere with revision control systems or builds. However, there are issues to work out about integration with Eclipse. Or alternatively, we could inject into a project, and then check it in. The problem here is that managing upgrading to a new revision of a library becomes more problematic, as you need to consider unwinding changes to the manifest, removing files no longer needed, etc. Overall, I think it's cleaner to consider injection to be a build step, rather than a project configuration step. You also need to consider how to avoid and/or handle file name conflicts. -- 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, reply using remove me as the subject.
Re: [android-developers] Re: Reusable Android library packaging: interest?
But one thought is that making this be a command may not be the best approach for integration into build systems. I'm thinking that packaging it as an ant macro in an antlib may be a better approach, with the underlying technology being a .zip file with the various pieces. Then, if you feel the need for a command, you could create an ant script, and simple shell scripts to invoke it. You assume I have the patience for Java. I put up with it for Android development, but that's about as far as I want to, at least for the initial versions. Part of the goal is to fully document all of the file structures and whatnot such that if somebody else wants to create a native Ant task, or a Rake task for use with JRuby, or whatever, they have all the info they need. And I will be happy to help with testing and coordination and all that. Tactically, I will be demonstrating Ant tasks that call out to the command, much like they call out to javac, jar, aapt, etc. today. And I'm not saying I'd never write an Ant task or Maven thingamajig or whatever myself someday, just that I'm not starting there. Overall, I think it's cleaner to consider injection to be a build step, rather than a project configuration step. I am up for trying to support both modes. This is the sort of thing -- like commands vs. Ant vs. Maven -- that really embodies the expression beauty lies in the eye of the beholder. Where possible, on those sorts of things, I'd like to let the developer make the call. You also need to consider how to avoid and/or handle file name conflicts. And resource ID conflicts. And dealing with the fact that you can't use R.layout with those resources. And a whole host of other annoyances that, individually, aren't particularly huge, but collectively represent a significant amount of sand in the gears. Thanks for the input! -- Mark Murphy (a Commons Guy) http://commonsware.com Android App Developer Books: http://commonsware.com/books.html -- 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, reply using remove me as the subject.
Re: [android-developers] Re: Reusable Android library packaging: interest?
Anyway, if you choose to go the parcel shell route, don't forget a parcel upgrade command. Personally, If I cannot upgrade easily to a new version of a library I wouldn't use it. Yup, it's in there. Thanks for the input! -- Mark Murphy (a Commons Guy) http://commonsware.com Android App Developer Books: http://commonsware.com/books.html -- 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
[android-developers] Re: Reusable Android library packaging: interest?
I didn't suggest writing any Java code. I didn't suggest writing any ant tasks in Java. I said to create an antlib (though I should have said library of ant definitions to be used with include/), which is entirely in XML. That's part of why I suggested this approach, as it would avoid the need for coding the commands in some language or other, and leverage the coding already done for the EXISTING ant tasks. I've written Ant tasks in Java. I see no need for it in this project; I think we're on the same page there. Anyway, my point was primarily implementation -- I think the implementation will work out more simply and portably if the bulk of it is done with existing ant tasks. There might be need for some code to handle things like resource conflicts. I suspect this could be handled well with XSLT scripts called from ant, though if it gets complex, I'd recommend against doing the complex logic parts in XSLT. XSLT makes manipulating XML very easy, but general computation very hard! But you could produce an XML file of mappings and drive the XSLT using that. Now of course, you're about to tell me you have no patience for ant, either! But you've got to have patience for SOMETHING... On Apr 5, 4:45 am, Mark Murphy mmur...@commonsware.com wrote: But one thought is that making this be a command may not be the best approach for integration into build systems. I'm thinking that packaging it as an ant macro in an antlib may be a better approach, with the underlying technology being a .zip file with the various pieces. Then, if you feel the need for a command, you could create an ant script, and simple shell scripts to invoke it. You assume I have the patience for Java. I put up with it for Android development, but that's about as far as I want to, at least for the initial versions. Part of the goal is to fully document all of the file structures and whatnot such that if somebody else wants to create a native Ant task, or a Rake task for use with JRuby, or whatever, they have all the info they need. And I will be happy to help with testing and coordination and all that. Tactically, I will be demonstrating Ant tasks that call out to the command, much like they call out to javac, jar, aapt, etc. today. And I'm not saying I'd never write an Ant task or Maven thingamajig or whatever myself someday, just that I'm not starting there. Overall, I think it's cleaner to consider injection to be a build step, rather than a project configuration step. I am up for trying to support both modes. This is the sort of thing -- like commands vs. Ant vs. Maven -- that really embodies the expression beauty lies in the eye of the beholder. Where possible, on those sorts of things, I'd like to let the developer make the call. You also need to consider how to avoid and/or handle file name conflicts. And resource ID conflicts. And dealing with the fact that you can't use R.layout with those resources. And a whole host of other annoyances that, individually, aren't particularly huge, but collectively represent a significant amount of sand in the gears. Thanks for the input! -- 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, reply using remove me as the subject.
[android-developers] Re: Reusable Android library packaging: interest?
I like the idea and as far as I know this is already possible to some extend by using the Maven Android Plugin. However this is really a suboptimal way in terms of component reuse on the device. Ideally it would even go further and get to a stage where a app could declare a dependency to a widget, library, intent or whatever and some central repository would be providing it for download. This would be similar to how e.g maven treats dependencies and downloads them on the fly when needed or even closer to Android how Linux package management systems like apt or rpm handle dependencies. The only problem with this approach is that it requires a strong open source community supporting the distribtution mechanism and at thist age I have my doubts this could be achieved on Android. Would be great though! manfred -- 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, reply using remove me as the subject.
[android-developers] Re: Reusable Android library packaging: interest?
I am interested - I have the same issues even sharing with my own libraries - In some ways the an approach might be to simply import both the code and the resources into the project if that were possible - The biggest issue I run across is resources which don't seem to get imported properly when I build my projects as two separate eclipse projects or two IntelliJ modules , the common widgets and the project specific code. -- 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, reply using remove me as the subject.
[android-developers] Re: Reusable Android library packaging: interest?
Hello Mark, You are absolutely right: support for reusable components other than pure Java code (and Java resources) is sorely missed. I personally think Google should step up and add this kind of support to the Android eclipse plugin. In my opinion, the problem of lack of tool support is minor when batch packaging. Using ant it is easy to copy the content of third party libraries. Of course a lack of standards does mean that no viable marketplace for this kind of reusable Android components can emerge. I believe the real problem lies when developing in-house libraries for multiple applications. As maybe 98% or more of the developers use eclipse (just guestimating), eclipse support for reusable (in-house) components is a must for getting this concept off the ground (imho). When developing your own components is easy (just being able add the library Android project as a dependency to your application project, and not having to worry about resources etc.), a need to package and distribute library projects for external use will surely emerge. Ant can actually fill in most of this need already, although a standardised format and automatic dependency resolving (maven?) will surely help. Anyway, if you choose to go the parcel shell route, don't forget a parcel upgrade command. Personally, If I cannot upgrade easily to a new version of a library I wouldn't use it. -- 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, reply using remove me as the subject.
[android-developers] Re: Reusable Android library packaging: interest?
Mark, I perfectly understand where you are coming from and support the motion. The 'parcel' shell would be fine, I can see how it will be welcome amongst Java devs (e.g. Grails does the same). Something I would like to get more details on is the storage mechanism of parcels on a local machine (maven repo has an advantage here, but of course, not everyone is using maven). If it can be made not too prescriptive regarding the project structure, it will have more success. Your reusable components http://commonsware.com/cwac are an ideal testbed for the concept, would love to see what you got already. Thanks, Andrew -- 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, reply using remove me as the subject.
[android-developers] Re: Reusable Android library packaging: interest?
To be honest, I would prefer to be able to specify package dependencies, much like linux distros do. That way I wouldn't have to bloat my app with source from other libs and I would make a non open source app a dependency even. However, I don't think we can do that without Google getting involved. I haven't yet tried to bundle a any libs in my APK's but I am planning on doing that soon. You make it sound like it is quite a hassle to do so. I'm always interesting in things that make my life easier. David Shellabarger http://www.goldfishview.com On Mar 29, 10:19 am, 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.
[android-developers] Re: Reusable Android library packaging: interest?
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.
[android-developers] Re: Reusable Android library packaging: interest?
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
Re: [android-developers] Re: Reusable Android library packaging: interest?
Gaunt Face wrote: 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. Indubitably. That's why I'm trying to gauge interest. 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. That's awful for maintainability. What happens when the next version of the widget is released by it's author? Your approach also assumes open source. If you are not in position to recompile the widget, your ability to change things (e.g., naming conventions) is more limited. Part of what would need to accompany the parcel system is guidance to those creating reusable widgets for how to enable knobs and levers for reusers to turn and, um, leverage. Would you have any idea of how to keep these parcel's up to date? If you tinker with the innards, the way you propose, you're on your own. This is no different than tinkering with the innards of a CPAN module in Perl, a Ruby gem, a Rails vendor plugin, a Linux package, a Java JAR via a decompiler, etc. A parcel can be extracted (opposite of injecting) from a project. Updating is extracting the old and injecting the new. The Android build system makes this a lot more icky than, say, updating a Ruby gem, but much of the ick can be confined to the parcel engine itself. Keep us posted on what you decide to do. Will do, and thanks for the feedback! -- 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 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.
[android-developers] Re: Reusable Android library packaging: interest?
I'd be very interested, and willing to lend a hand. I've been collecting my own library of tricks and widgets and even sharing within my own apps it's cumbersome. On Mar 29, 1:41 pm, Mark Murphy mmur...@commonsware.com wrote: Gaunt Face wrote: 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. Indubitably. That's why I'm trying to gauge interest. 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. That's awful for maintainability. What happens when the next version of the widget is released by it's author? Your approach also assumes open source. If you are not in position to recompile the widget, your ability to change things (e.g., naming conventions) is more limited. Part of what would need to accompany the parcel system is guidance to those creating reusable widgets for how to enable knobs and levers for reusers to turn and, um, leverage. Would you have any idea of how to keep these parcel's up to date? If you tinker with the innards, the way you propose, you're on your own. This is no different than tinkering with the innards of a CPAN module in Perl, a Ruby gem, a Rails vendor plugin, a Linux package, a Java JAR via a decompiler, etc. A parcel can be extracted (opposite of injecting) from a project. Updating is extracting the old and injecting the new. The Android build system makes this a lot more icky than, say, updating a Ruby gem, but much of the ick can be confined to the parcel engine itself. Keep us posted on what you decide to do. Will do, and thanks for the feedback! -- 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 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.
