search

jasonpolites / gesture-imageview

Implements pinch-zoom, rotate, pan as an ImageView for Android 2.1+
1.15k stars 501 forks source link

Preserve ImageView inheritance hierarchy? #4

Closed jcogilvie closed 12 years ago

jcogilvie commented 12 years ago

I'm trying to make use of this library, which is exactly what I was looking for; but there are a million places in my code where I refer to ImageViews as ImageViews specifically, and since a GestureImageView doesn't extend ImageView, I need to create a whole bunch of overloaded function calls in order to continue using my existing code base.

I'm wondering why you've chosen not to extend ImageView.

For reference, there's this old project here (http://code.google.com/p/android-pinch/) that does extend ImageView and provides similar functionality. I don't know if it will be of use to you or if you've seen it before.

jasonpolites commented 12 years ago

There are a bunch of methods on the ImageView class which are neither helpful or useful in the context of a pinch/zoom scenario, eg: setScaleType, setImageMatrix etc.. however...

There ARE several methods which this component SHOULD support, e.g. setImageDrawable, setColorFilter etc. When the component was originally developed it was for a very specific use-case and although many of these methods are useful initially the lack of support for them meant it made more sense to not even expose them rather than expose them but not have them work correctly.

At some point it should indeed be an extension of the ImageView, but this is non-trivial when considering different versions of the ImageView class and the behaviors therein (i.e. when new methods are added to the class in future versions of Android).

What methods specifically are you using in your codebase that you need to override? It may make sense to just implement these in the gesture-imageview to provide compatibility without misrepresenting the capabilities of the component.

jcogilvie commented 12 years ago

I think I know what you're getting at in terms of misrepresenting capability. One of the Android conventions (see, for example, ListView vs. ExpandableListView) is to simply override the parent method and throw an OperationNotSupportedException in cases where a given method is not supported for a particular implementation.

What that buys the end user is the ability to cast from GestureImageView to ImageView without a ClassCastException, which is extremely useful if one already has infrastructure that leverages the ImageView class. My application in particular has a huge amount of operation-queuing infrastructure and leverages a third-party image cache library. The image caching library is designed to take ImageViews as arguments, and if GestureImageView were a child of ImageView I could leverage all of that functionality; the same is true of my queuing infrastructure.

I definitely understand your concern re: the evolution of the ImageView base class in future versions of Android. It may be possible to just throw a warning if the max API version of the application is greater than whichever you have coded for, and put the responsibility on the developer to use it correctly.

Just my two cents. :)

I'm happy to chat further on the issue.

jasonpolites commented 12 years ago

Hmm.. you make some good points. I'll look at extending ImageView and throwing exceptions where appropriate. Thanks

jasonpolites commented 12 years ago

Code updated. GestureImageView now extends ImageView. See README for more details