TouchImageView: pinch zoom and pan for Android ImageView

The gap TouchImageView fills between ImageView and a gallery app

A plain Android ImageView draws a bitmap and applies a ScaleType. It does not respond to a two-finger pinch, it does not let you drag a zoomed image around, and it has no notion of a current zoom level you can read back. Anyone building a photo viewer ends up writing the same matrix math and gesture detection. TouchImageView is that work packaged as a subclass. The README describes the intent directly: it extends ImageView, supports everything ImageView does, and adds pinch zoom, dragging, fling, double tap zoom and "other animation polish", with the goal of mirroring zoomable images in Gallery apps as closely as possible. The audience is an Android developer who already has an ImageView in a layout and wants it to behave like the system gallery. It is not a general image loading library and it does not fetch or decode bitmaps for you.

How the view tracks zoom, scroll position and focus points

The mechanism visible in the README is a scale and translation state layered on top of the ImageView, exposed through a small API rather than through a custom XML attribute set. Zoom is expressed relative to the initial scale, not the original resource, which matters when you compare numbers across differently sized views. Focus points and scroll position are normalized: the getScrollPosition() documentation says the PointF coordinates range between 0 and 1 and denote a fraction from the left and top of the view, so the top left corner is (0, 0) and the bottom right is (1, 1). That normalization is what lets the setZoom(float scale, float focusX, float focusY) overload keep a chosen point anchored while the scale changes, and it is also what makes the mirroring example possible: two TouchImageViews can be kept in sync through OnTouchImageViewListener and setZoom(). Defaults are stated in the README: max zoom multiplier is 3, min zoom multiplier is 1, and TouchImageView.AUTOMATIC_MIN_ZOOM can be passed to setMinZoom so the whole image is visible. There is also setMaxZoomRatio(float max), which pins the max zoom to a fixed multiple of the min zoom instead of an absolute value, and setZoom(TouchImageView img), which copies scale, position and ScaleType from another instance. Two methods handle layout changes rather than gestures: setViewSizeChangeFixedPixel and setOrientationChangeFixedPixel decide which part of the image stays fixed when the view is resized or the screen rotates. The README points to ChangeSizeExampleActivity.java for advice on setting up a TouchImageView that will be resized, which is a hint that resizing is the fiddly case, not the basic one.

Installing TouchImageView from JitPack and a first zoomable image

The README says the repository is available on JitPack and shows the repository block you add to your Gradle configuration. Note that the README's own dependency example pins 1.4.1 as the "last SupportLib version" and otherwise uses a placeholder variable for the Android X line, so the version you actually want comes from the JitPack page rather than from a copied snippet.

allprojects {
    repositories {
        ...
        maven { url 'https://jitpack.io' }
    }
}

After the repository is registered, add the dependency. The README gives two coordinates: a SupportLib line fixed at 1.4.1 and an Android X line that uses a version variable.

dependencies {
    implementation 'com.github.MikeOrtiz:TouchImageView:1.4.1' // last SupportLib version
    // or
    implementation 'com.github.MikeOrtiz:TouchImageView:$LAST_VERSION' // Android X
}

With the dependency resolved, the first real use is the same as any custom view: put the fully qualified class name in your layout where the ImageView would go, then set the image and read the zoom state back. The README lists the accessors you would call for that: getCurrentZoom(), isZoomed(), getScrollPosition() and getZoomedRect(). A listener registered through OnTouchImageViewListener is how the sample app drives its mirroring and switch-image examples, and resetZoom() returns the view to its initial unzoomed state. The README does not document a custom XML attribute set, so zoom limits and focus are configured in code through setMaxZoom, setMinZoom, setMaxZoomRatio and setZoom, not in the layout file.

What TouchImageView does not do, and when to pick something else

The README's Limitations section is short and blunt: pinch image rotation is not supported, and the FIT_START and FIT_END scale types are not supported either. If your design calls for a rotated, free-form canvas, this view is the wrong tool, and no amount of calling setZoom will get you there. The second constraint is the project status. The README states it is in maintenance mode, and says issues are ignored but pull requests are not, with the instruction that if you need something done you should submit a PR. That is a real operational fact, not a formality: a bug you file may sit unread, while a patch you write has a path in. A third limit is scope. TouchImageView handles gestures and view state; it does not load images, cache them, or decode large bitmaps efficiently. If your problem is memory pressure from full-resolution photos, the zoom view is not the layer that solves it. As an alternative, a general purpose zoomable image widget that also owns loading and caching would cover more ground, at the cost of a larger dependency and its own abstraction over the view. TouchImageView's difference in approach is that it stays a view: it subclasses ImageView, keeps the API close to what ImageView already exposes, and leaves loading to whatever you already use.

Maintenance, releases and what the MIT license leaves you

The repository is not archived, and the last push was on 2026-09-11, so work is still landing on the default branch. The release history is uneven: 3.7 and 3.7.1 both landed on 2025-04-22, and 3.7.2 on 2026-04-20. Read together with the maintenance-mode note, that pattern suggests the branch moves more often than tags are cut, which is worth knowing if you depend on published artifacts rather than on a commit. The upgrade cost is shaped by the README's own dependency example: the SupportLib line is frozen at 1.4.1 and the Android X line is the one that tracks current versions, so a project still on the old support libraries is effectively pinned while an Android X project can move. The license is MIT, which permits commercial and closed-source use and requires preserving the copyright notice and permission text; the README points to the LICENSE file for the full terms. That is a description of the license, not legal advice, and if the notice obligations matter to your organization, have someone read LICENSE.txt rather than this paragraph.

Editorial conclusion

Adopt TouchImageView if you need a zoomable ImageView inside a ViewPager-style gallery and you are willing to submit a pull request when you hit a gap, because the README states issues are ignored while pull requests are not. Do not adopt it if you need pinch rotation, FIT_START or FIT_END, or if you expect upstream fixes without contributing them. Before wiring it in, verify that the artifact coordinate you intend to use (the SupportLib 1.4.1 line or the Android X line) matches your project, and check the current release tag on JitPack rather than copying a version from an old blog post.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MikeOrtiz/TouchImageView on GitHub
4. README
5. Releases