前提
やれるパワーがある人はやって下さい。潤沢な開発リソースがある上で、内蔵 PDF ビュワーを実装することが「他のアプリには無い価値を提供する」為の主な目的である場合はこの記事では対象としません。
この記事の趣旨は、これから実装する上で方針を悩んでる場合や客観的な視点で顧客を説得する必要がある場合の為の参考です。
現状
まず iOS とは異なり WebView は PDF の描画に対応しておらず、Intent が飛ぶかダウンロードが始まります。PDF.js を利用して無茶して読ませることは可能なようですが、快適では無いでしょう。
プラットフォームの API は Android 5.0 以降のみ存在します。これでひとつのドキュメントを全ページ表示する場合、
- ファイルオブジェクトを作成し
- PdfRenderer オブジェクトとして初期化し
- オブジェクトからページ数を取得
- openPage() で取得した Page オブジェクトを ImageView に対し描画、close() 、を全ページに対して実施
- PdfRender のクローズ
という実装を行う必要があります。
ImageView に描画、ということは埋め込みリンク等には対応しません。ピンチイン/アウトやズーム等も独自に対応する必要があります（ImageView に対して操作を提供するライブラリは使用出来るでしょう）。
サードパーティのライブラリは基本的に有償ライセンスのものが多く、無償の場合は実装が古く Deprecated となっているか大抵 GPL 互換のライセンスであり、商用利用の場合は注意が必要だったりします。現状 Apache 2.0 ライセンスのもと利用可能かつアクティブなライブラリとしては barteksc/AndroidPdfViewer がありました。16MB 程の各アーキテクチャに向けたネイティブ実装を持つライブラリに依存する為、APK のサイズは肥大化するようです。
何故こんなことになっているのか
そもそも Android は Intent という仕組みにおいて、各ファイルや URL 等をうまく処理出来るアプリがあればそちらに処理を委ねてよきに図らうというプラットフォーム自体の方針があります。Android ユーザーはその操作体系に慣れているので、Intent を利用することによるユーザー体験を損ねることは少ない筈です。Intent を発行し、対応出来るアプリが無ければ Adobe Reader アプリ等のストアへの案内を行うというのが妥当な実装ではないでしょうか。
勿論 Intent を飛ばすか内部ビュワーで表示するか選択出来るのが尚親切だというのはあるでしょう。しかしその為に、
- スタンドアロンなビュワーアプリ作成を想定されているような API を使用し、PDF の細かい仕様に対応しながら実装、メンテナンスを続けていくか
- PDF.js を使用して WebView の中に無理矢理重くて操作感の厳しい PDF をレンダリングするか
- 有償のライブラリの試用版を片っ端から比較し（メールアドレスの登録が必要だったりと別の手間も発生する場合がある）選定、各アプリ毎にライセンス料を支払い利用するか
- APK サイズの肥大化を許容した上でネイティブ実装を持つライブラリを利用するか
のトレードオフが許せるか、というのはよく検討が必要です。1/2/3 の方法を選択する場合はその部分だけでかるくひとつのアプリを作成するくらいの工数を見積りたいところです。
barteksc/AndroidPdfViewer については正直この記事を書いている途中に発見したのですが、軽く見た感じ提供されている API がいい感じであり要件を満たすならば有力な選択肢になるかもしれません。
結論
ディレクションする上で Android を使用したことのない iOS ユーザーが自分の価値観だけでエンジニアにアプリのユーザー体験を説教するのをやめろ