How do their APIs compare?

These two projects have fundamentally different kinds of "APIs" — one is a UI widget API for Android, the other is a networked trading/data-access API — so the comparison is really about design shape rather than overlapping functionality.

baseflow/photoview: a widget-configuration API

Photoview's public surface is a single custom View (PhotoView, extending AppCompatImageView) backed by a delegate class, PhotoViewAttacher, that does the real work [photoview/src/main/java/com/github/chrisbanes/photoview/PhotoView.java:L1-L32]. The API style is classic Android:

• Fluent setter/listener pattern. Consumers call setOnPhotoTapListener, setOnOutsidePhotoTapListener, setOnMatrixChangeListener, setOnSingleFlingListener, setOnScaleChangeListener, setOnDoubleTapListener, etc., each wiring a callback interface into the attacher [photoview/src/main/java/com/github/chrisbanes/photoview/PhotoViewAttacher.java:L399-L438] [photoview/src/main/java/com/github/chrisbanes/photoview/PhotoViewAttacher.java:L239-L278].
• Callback interfaces like OnPhotoTapListener define single-method contracts (onPhotoTap(ImageView view, float x, float y)) with x/y normalized as percentages of the drawable [photoview/src/main/java/com/github/chrisbanes/photoview/OnPhotoTapListener.java:L9-L23].
• Imperative state control: setScale(float), setScale(float, boolean animate), setScale(float, focalX, focalY, animate), plus setMinimumScale/setMediumScale/setMaximumScale/setScaleLevels, with bounds validation via Util.checkZoomLevels and an IllegalArgumentException if scale is out of range [photoview/src/main/java/com/github/chrisbanes/photoview/PhotoViewAttacher.java:L447-L459] [photoview/src/main/java/com/github/chrisbanes/photoview/PhotoViewAttacher.java:L399-L416].
• Everything is synchronous, on the main/UI thread, and tightly coupled to Android's MotionEvent/GestureDetector/Matrix types — there's no network, async, or exchange-agnostic abstraction here, just gesture handling plumbed into a Matrix transform, as seen in the double-tap gesture logic [photoview/src/main/java/com/github/chrisbanes/photoview/PhotoViewAttacher.java:L199-L238].

Given the project's stale status noted in the RepoPilot verdict ("WAIT — Stale — last commit 4y ago"), this API should be treated as frozen/legacy rather than evolving.

knowm/xchange: a unified exchange-abstraction API

XChange's API is service-oriented and network-facing, designed to normalize 60+ different cryptocurrency exchange REST/WebSocket APIs behind one interface:

• Factory + interface pattern: ExchangeFactory.INSTANCE.createExchange(BitstampExchange.class) returns a generic Exchange object; concrete exchange classes (BitstampExchange, etc.) are interchangeable behind the same interface [README.md:L36-L45].
• Service decomposition: from an Exchange you obtain typed services — MarketDataService (public data like getTicker), AccountService (getAccountInfo), TradeService — each representing a slice of exchange functionality [README.md:L36-L67].
• Auth via configuration object: ExchangeSpecification holds credentials (API key/secret, and exchange-specific fields like Bitstamp's username or Coinbase Pro's passphrase), decoupling authentication setup from service calls [README.md:L47-L54].
• Streaming/reactive variant: a parallel StreamingExchange/StreamingExchangeFactory API returns RxJava Observable/Disposable streams for real-time trades and order books instead of polling, e.g. getStreamingMarketDataService().getTrades(...).subscribe(...) [README.md:L73-L108].
• Per-exchange DTOs and exceptions follow a consistent Jackson