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.
