Thanks. Yes, that was the "feeling" I was getting... that Android's use of R.resource is (although easy) is inflexible regarding external libraries. My library jar contains internal icon resources it needs, but no other dependent APK would ever access them directly. It would have been nice for Android to follow typical Java practices regarding resources so they can be bundled in jars like we are accustomed to.
On Feb 25, 4:28 pm, Mark Murphy <[email protected]> wrote: > Ron wrote: > > How would I change setIcon(R.drawable.myIcon) using your technique? > > Are you saying do a global change in the base project by replacing all > > references of R.drawable.* with getResources().getDrawable > > (R.drawable.*)? Then during runtime it will properly resolve to the > > res directory of the base library not the res directory of the project > > using the library? > > No. > > I'm not sure where setIcon() is, so let's talk concretely about > ImageView#setImageResource(), which may be what you were referring to. > > setImageResource() uses a Drawable resource. That resource will always > be from the APK in which setImageResource() happens to be called. That > is true regardless of whether the call to setImageResource() in in > classes compiled into the APK directly or incorporated via some JAR. > > So, let us suppose you want to ship a JAR that needs to call > ImageView#setImageResource() for some reason. That JAR cannot embed an > R.drawable.something_or_another resource ID, because the JAR does not > have an R.java, because the JAR does not have its own resources -- > resources come from the APK. > > This means, for the JAR to use ImageView#setImageResource(), it has to > get the int resourceId from someplace other than hard-wiring in a > resource ID. The most likely solution is to have the JAR get the > resource ID from whatever code is in the APK is using the JAR. > > Remember: R.drawable.something_or_another is just an int. It *points to* > a Drawable, but R.drawable.something_or_another is just an int. > > So, in the JAR, you might have: > > void setMeAnIcon(int resourceId) { > myImageView.setResourceId(resourceId); > > } > > And in the APK, you might have: > > void ohICannotThinkOfAGoodMethodName() { > anObjectFromMyJAR.setMeAnIcon(R.drawable.my_icon); > > } > > The APK keeps the resources. The JAR merely uses passed-in resource IDs > in its calls to the Android API that need resource IDs. > > Since JARs cannot package resources, if you want to distribute resources > with your JAR, you will have to handle that yourself. For example, let's > suppose you created an awesome Android-friendly SOAP library, and for > some reason you want to ship some icons with it. You would need to whip > up a ZIP file that includes your JAR, your icons, and instructions that > say "yo, if you want to use these icons, that's cool, just put them in > res/drawable/ and use them in our API calls". Admittedly, this is > somewhat annoying -- it'd be nice if we could use files stored in the > JAR itself -- but it's not the end of the world, either. > > -- > Mark Murphy (a Commons Guy)http://commonsware.com > _The Busy Coder's Guide to Android Development_ Version 2.0 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 -~----------~----~----~----~------~----~------~--~---
