LASSIC Media らしくメディア
アプリにファイルプレビュー機能を実装、外注で対応
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- アプリ内でPDFやOffice文書、画像を表示するファイルプレビュー機能は、iOSではQuickLookフレームワークのQLPreviewControllerが標準の実装手段です*1*2。
- AndroidにはQuickLookに相当する単一の標準UIはなく、ACTION_VIEWインテントによる外部アプリ連携とFileProviderの併用、またはPdfRendererによる自前描画のいずれかを選ぶ設計判断が必要です*5*6。
- 対応形式の広さ・自社アプリ内での表示か外部アプリ連携か・社外への持ち出し防止の要件によって、内製か外注かの判断が分かれます。
目次
アプリのファイルプレビュー機能とは、離脱させずに文書を表示する仕組み
アプリのファイルプレビュー機能とは、PDF・Office文書・画像・動画などのファイルを、専用アプリへ切り替えずにアプリ内で直接表示する仕組みを指します。iOSではAppleがQuickLookフレームワークを提供し、その中核をQLPreviewControllerというビューコントローラーが担っています*1*2。
業務アプリで文書共有・チャット添付・帳票確認などの場面を想定すると、ファイルを開くたびに別アプリへ遷移する体験は業務の流れを分断します。アプリ内でそのまま内容を確認できれば、確認作業の手離れがよくなり、社外への持ち出しを防ぐ制御もアプリ側で一元的に管理できます。
iOS——QuickLookのQLPreviewControllerが担う標準プレビュー
QuickLookはAppleが提供するフレームワークで、ファイルの内容を確認するためのプレビュー機能をアプリに組み込む手段を提供します*1。中核となるQLPreviewControllerは、プレビュー対象のアイテムを表示するために特化したビューコントローラーです*2。
QLPreviewControllerを使う際は、QLPreviewControllerDataSourceプロトコルに準拠したデータソースを実装します。データソースはプレビューするアイテムの数と、各アイテムを表すQLPreviewItemを返す役割を担います*2。表示中の挙動を細かく制御したい場合は、QLPreviewControllerDelegateプロトコルも併用します*2。
QuickLookが対応する形式には、画像・動画・PDF・テキストといった一般的なファイルが含まれます*1。文書共有アプリでこの仕組みを使うと、受信したPDFや画像をアプリ内のプレビュー画面でそのまま開けます。別アプリへ切り替える手間がかかりません。
PDFを高度に扱いたい場合は、QuickLookに加えてPDFKitフレームワークを使う選択肢もあります。PDFKitはPDF文書の表示・操作を行うためのフレームワークで、PDFViewというビュークラスを中心にページ送りやテキスト検索などの機能を提供します*3。QuickLookは複数形式に対応する汎用プレビューで、PDFKitはPDFに特化した細かな制御が必要な場面に向いています。
Android——ACTION_VIEWによる外部連携とPdfRendererによる自前描画
ACTION_VIEWインテントとFileProviderによる外部アプリ連携
Androidには、iOSのQuickLookに相当する単一の標準プレビューUIは用意されていません。代わりに広く使われるのが、ACTION_VIEWインテント(暗黙的インテント。データの種類だけを指定し、処理できるアプリをシステムに選ばせる仕組み)で、対象ファイルを表示できる別アプリを起動する仕組みです*5。
この方式で自社アプリ内のファイルを他アプリに渡すには、FileProvider(Androidのcontent providerの特殊なサブクラス。アプリ内ファイルへの限定的なアクセスを提供する)を使い、file://形式ではなくcontent://形式のURIを生成します*4。FileProviderはアプリのマニフェストに宣言し、共有可能なディレクトリをXMLリソースで指定した上で、getUriForFileメソッドでURIを取得する流れになります*4。
取得したcontent URIをACTION_VIEWインテントのデータにセットし、Intent.FLAG_GRANT_READ_URI_PERMISSIONを付与して起動すると、対象ファイルを開けるアプリが表示するプレビュー画面に遷移します*4*5。起動前にはresolveActivityでファイルを処理できるアプリの有無を確認しておく必要があります*5。
PdfRendererによるPDFの自前描画
アプリを離れずにPDFをその場で表示したい場合は、PdfRendererクラスを使ってアプリ内に直接描画するアプローチもあります*6。PdfRendererはPDF文書を開き、ページ単位でビットマップとしてレンダリングするためのクラスで、Android 5.0(API level 21)以降で利用できます*6。
PdfRendererを使う場合、外部アプリへの遷移は発生しません。その代わり、ページ送りのUIや拡大縮小といった表示機能は自前で実装する必要があります。ACTION_VIEW連携が外部アプリのUIをそのまま借りる方式であるのに対し、PdfRendererは表示体験を自社側で完全に制御できる方式です*6。
iOSとAndroidの実装アプローチの違い
両OSのアプローチを整理すると次の通りです。
| 項目 | iOS | Android |
|---|---|---|
| 標準UIの有無 | QLPreviewControllerが標準UIを提供*2 | 単一の標準UIはなし*5 |
| 表示の実現方法 | 同一フレームワークでアプリ内表示*1 | 外部アプリ連携またはPdfRendererで自前描画*5*6 |
| ファイル受け渡し | QLPreviewItemでアプリ内に保持*2 | FileProviderのcontent URIで他アプリに渡す*4 |
| PDF特化の選択肢 | PDFKitで注釈・検索まで対応*3 | PdfRendererでページ単位に描画*6 |
| 対応API/OSバージョン | iOS 11以降(PDFKit)*3 | API level 21以降(PdfRenderer)*6 |
業務アプリでの実装の勘所——対応形式・持ち出し防止・表示速度
文書共有・チャット添付・帳票確認といった業務アプリでは、想定する対応形式を先に絞り込むことが実装の出発点になります。PDF・Office文書・画像だけに限定するのか、動画や独自形式まで広げるのかで、iOS側はQuickLookで足りるかPDFKitの併用が必要かが変わります*1*3。
社外への持ち出し防止を重視する業務アプリでは、Androidの実装方式の選択が特に重要になります。ACTION_VIEW連携で外部アプリに渡すと、渡した先のアプリでの保存・共有操作まではアプリ側で制御できません*5。この経路を避け、社内文書をアプリ内にとどめたい場合は、PdfRendererによる自前描画のように外部アプリへ遷移しない方式を選ぶ必要があります*6。
この判断を誤ると、意図せず文書が外部アプリの履歴やキャッシュに残るおそれがあります*4*5。FileProviderのURI権限は一時的な付与であっても、渡した先のアプリ内でのファイル取り扱いはアプリの管理範囲外になるためです。
表示速度も業務での使い勝手に直結します。大きなPDFやページ数の多い文書をPdfRendererで自前描画する場合、ページごとのビットマップ生成とメモリ管理を適切に設計しないと、スクロール時の描画が重くなる場合があります*6。この作業を内製で担うには、iOSのQuickLook/PDFKit実装知識、AndroidのFileProvider権限設計、PdfRendererのメモリ管理という複数領域の知識が要ります。
内製と外注の分かれ目——両OS対応と持ち出し防止要件の重さ
片方のOSのみで、対応形式もPDFと画像程度に絞れる場合は、自社での実装を検討しやすい領域です。判断が分かれるのは、iOS・Android両対応が必須で、かつ社外への持ち出し防止のような業務要件が重なる場合に限られます。
専門パートナーに委託する場合、依頼範囲の広さが選定の分かれ目です。iOS側のQuickLook/PDFKit実装からAndroid側のFileProvider権限設計・PdfRendererによる自前描画までを一括して依頼できるか、加えて対応形式の拡張やセキュリティ要件のヒアリングまで対応できるかを確認します。内製では既存の開発担当者が通常業務と並行して対応することになり、両OSの検証に割ける時間が限られる場合があります。
。対応OS・対応形式の広さ・持ち出し防止要件の有無によって必要な工数は変わってきます。現状のアプリ構成を診断したうえで、内製・外注の切り分けを検討することが実務的です。
まとめ：ファイルプレビュー実装で押さえる3つの判断軸
本稿ではアプリのファイルプレビュー機能について、iOSとAndroidそれぞれの実装方式を公式情報をもとに整理しました。要点は3つに集約できます。第一に、iOSではQuickLookフレームワークのQLPreviewControllerが標準のプレビューUIを提供します*1*2。第二に、AndroidにはiOSに相当する単一の標準UIがなく、ACTION_VIEWによる外部アプリ連携かPdfRendererによる自前描画かを選ぶ設計判断が必要です*5*6。第三に、対応形式の広さと社外への持ち出し防止要件の重さによって、内製と外注の判断材料が変わります。
よくある質問
iOSでファイルプレビュー機能を実装する場合、QuickLookとPDFKitのどちらを使えばよいですか。
画像・PDF・Office文書など複数形式を汎用的にプレビューしたい場合はQuickLookのQLPreviewControllerが適しています*1*2。PDFに限定してページ送りやテキスト検索まで細かく制御したい場合はPDFKitのPDFViewを使う選択になります*3。両方を組み合わせて使うことも可能です。
AndroidでもiOSのQuickLookのような標準プレビュー機能はありますか。
Androidには、iOSのQuickLookに相当する単一の標準プレビューUIは用意されていません*5。ACTION_VIEWインテントとFileProviderを使って対応する外部アプリにプレビューを委ねるか、PdfRendererでPDFをアプリ内に自前描画するか、いずれかを選ぶ必要があります*5*6。
ACTION_VIEWで他アプリにファイルを渡すとき、なぜFileProviderが必要ですか。
Androidではfile://形式のURIを他アプリへ直接渡すことが制限されており、content://形式のURIをアクセス権限を制御した形で生成する仕組みとしてFileProviderを使います*4。FileProviderをマニフェストに宣言し、共有可能なディレクトリを指定したうえでgetUriForFileメソッドを呼び出す流れになります*4。
社外への文書の持ち出しを防ぎたい場合、どちらの実装方式を選ぶべきですか。
ACTION_VIEWで外部アプリに文書を渡すと、渡した先での保存・共有操作までは自社アプリの管理範囲外になります*5。社外への持ち出しを防ぎたい場合は、外部アプリへ遷移しないPdfRendererによる自前描画のような方式を選ぶ必要があります*6。
ファイルプレビュー機能の実装を外部に委託する場合、何を確認すればよいですか。
対応OS(iOS/Android)の範囲、対応させたいファイル形式の一覧、社外への持ち出し防止のような業務要件の有無をまず確認します。加えて既存アプリのアーキテクチャへの組み込み方法を委託先とすり合わせることが大切です。契約前に検証環境での確認範囲を明確にしておくと、リリース後のトラブルを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple「Quick Look」（Apple Developer Documentation）（https://developer.apple.com/documentation/quicklook）
- *2 出典：Apple「QLPreviewController」（Apple Developer Documentation）（https://developer.apple.com/documentation/quicklook/qlpreviewcontroller）
- *3 出典：Apple「PDFKit」（Apple Developer Documentation）（https://developer.apple.com/documentation/pdfkit）
- *4 出典：Android Developers「Sharing files」（Setting Up File Sharing）（https://developer.android.com/training/secure-file-sharing/setup-sharing）
- *5 出典：Android Developers「Common Intents」（https://developer.android.com/guide/components/intents-common）
- *6 出典：Android Developers「PdfRenderer」（API Reference）（https://developer.android.com/reference/android/graphics/pdf/PdfRenderer）
