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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] 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.
