ios - ページングとズームが有効な UIScrollView 画像/写真ビューア

Question

UIScrollViewOK、この問題についてインターネット上に公式の場所を作る時が来たと思います:ページングとズームを備えたフォトビューアーの作り方。私の仲間のUIScrollViewハッカーを歓迎します。

UIScrollViewページングを有効にして、組み込みの写真アプリのように表示しUIImageViewsています。（これはまだ聞き覚えがありますか？）

github で次のプロジェクトを見つけました。

https://github.com/andreyvit/ScrollingMadness/wiki

ページングが有効なときにスクロールビューでズームを実装する方法を示します。他の誰かがこれを試した場合、実際にはUIScrollViewサブクラスを削除してネイティブクラスを使用する必要がありました。そうしないと機能しません。スクロールビューがタッチイベントをインターセプトする方法に関連する 3.0 SDK の変更が原因だと思います。

したがって、ズームを開始するときに他のすべてのビューを削除し、現在のビューをの (0, 0) に移動して、などscrollviewを更新するというcontentsize考え方です。次に、ズームを 1.0f に戻すと、他のビューが追加されて戻されます。物事はすべて元に戻ります。

とにかく、そのプロジェクトはシミュレーターで完全に機能しますが、デバイスでは、サイズ変更中のビューの厄介な動きがあります。これは、サイズ変更中のビューのcontentsize/offsetなどを変更していることが原因のようです。このビューを移動する必要があります。そうしないと、他のビューによって残された空白を左にパンできます。

3.0 SDK リリースノートの「既知の問題」に興味深いメモが 1 つ見つかりました。

UIScrollView: ズーム後、コンテンツインセットが無視され、コンテンツが間違った位置に残る。

この種の音は、ここで起こっていることのように聞こえます。ズームインすると、オフセットなどを変更したため、ビューが画面外に移動します。

私はすでにこれに何時間も費やしてきましたが、これがうまくいかないという悲しいことに気付くのが遅くなりました.

Three20 のフォトビューアーは論外です。重量が重すぎて、不要な UI やその他の動作が多すぎます。

組み込みの写真アプリは魔法のようです。画像をズームインして端までパンすると、現在の写真が隣の写真とは独立して移動しますが、これを標準で試した場合とは異なりますUIScrollView。

の入れ子についての議論を見てきましUIScrollViewたが、本当に行きたくありません。

これを標準で管理した人はいますかUIScrollView(そして 2.2 および 3.0 SDK で動作します)? 独自のズーム + バウンス + パン + ページングコードをローリングするのは好きではありません。

score 43 · Accepted Answer

アップデート

以下のニュースのため、以前の回答を削除しました...

聞いたことのない方に朗報です。Apple は、iphone 開発者プログラムのすべてのメンバーに 2010 WWDC セッションビデオをリリースしました。議論されたトピックの 1 つは、彼らが写真アプリを作成した方法です!!! 彼らは非常によく似たアプリを段階的に構築し、すべてのコードを無料で利用できるようにしました。

プライベート API も使用しません。サンプルコードのダウンロードへのリンクです。アクセスするには、おそらくログインする必要があります。

これをチェックして

また、iTunes WWDC ページへのリンクは次のとおりです。

これをチェックして

score 32 · Accepted Answer

MWPhotoBrowserというシンプルで使いやすいフォトブラウザを作成しました。Three20 は重すぎて肥大化しすぎたので作成することにしました。必要なのはフォトビューアーだけでした。

MWPhotoBrowser は、UIImage オブジェクト、またはファイル、Web 画像、またはライブラリアセットへの URL を提供することにより、1 つまたは複数の画像を表示できます。フォトブラウザーは、Web からの写真のダウンロードとキャッシュをシームレスに処理します。写真はズームおよびパンでき、オプションの (カスタマイズ可能な) キャプションを表示できます。ブラウザーを使用して、ユーザーがグリッドビューまたはメインイメージビューのいずれかを使用して 1 つまたは複数の写真を選択できるようにすることもできます。

score 19 · Accepted Answer

あなたは、UIScrollViews の入れ子についての議論を見たが、そこには行きたくないと言いますが、それが行くべき道です! それは簡単かつうまく機能します。

これは基本的に、Apple が PhotoScroller の例 (および Jonah の回答にリンクされている 2010 年の WWDC トーク) で行っていることです。これらの例でのみ、複雑なタイリングやその他のメモリ管理が多数追加されています。タイリングなどを必要とせず、これらの例を調べてそれに関連するビットを削除しようとしない場合、UIScrollViews をネストする基本的な原則は実際には非常に単純です。

外側の UIScrollView を作成し、pagingEnabled = true に設定します。それをメインビューに追加し、その幅と高さをメインビューの幅と高さに設定します。
画像が必要な数の内部 UIScrollViews を作成します。幅と高さをメインビューの幅と高さに設定します。それらをサブビューとして外側の UIScrollView に追加し、それぞれを左から右に並べます。
外側の UIScrollView のコンテンツサイズを、すべての内側の UIScrollView の幅の合計に設定します ([メインビューの幅]*[画像の数] に等しい)。
画像の UIImageViews を内側の UIScrollViews に追加し、各内側の UIScrollView に 1 つの UIImageView を追加します。各 UIScrollView のコンテンツサイズを各 UIImageView のサイズに設定します。
内側の UIScrollView ごとに最小ズームスケールと最大ズームスケールを設定し、内側の UIScrollView の各デリゲートをビューコントローラーに設定します。デリゲートの viewForZoomingInScrollView で、渡された UIScrollView の適切な UIImageView を返します。(これを行うには、各 UIImageView を NSArray に保持し、対応する UIScrollView のタグプロパティを適切な UIImageView のインデックスに設定します。次に、viewForZoomingInScrollView に渡された UIScrollView のタグを読み取り、NSArray から適切な UIImageView を返すことができます)。 .

それでおしまい。写真アプリと同じように機能します。

大量の写真がある場合、メモリを節約するために、2 つの内部 UIScrollView と 2 つの UIImagesView を使用できます。次に、それらを動的に切り替えて、外側の UIScrollView 内で位置を移動し、ユーザーが外側の UIScrollView をスクロールすると画像を変更します。少し複雑ですが、原理は同じです。

score 6 · Accepted Answer

私はネイティブの写真アプリをいじってみましたが、単一の UIScrollView を使用していると自信を持って言えると思います。景品はこれです: 画像を拡大し、左右に引っ張ってください。次または前の写真が表示されます。十分に強く引っ張ると、1.0f ズームで次の写真にページングすることさえできます。裏返すと、以前にズームした写真も 1.0f ズームに戻ります。

明らかに、Photos.app を作成したのは私ではありませんが、彼らがどのようにそれを行ったかについて、大雑把な推測をしてみます。

単一の UIScrollView と単一の UIScrollViewDelegate
UIScrollView に UIImageView の子を設定する
聞くscrollViewDidScroll:
いくつかの計算を行い、現在どのページにいるかを把握します
聞くviewForZoomingInScrollView:
ページインデックスに応じて異なるビューを返す
コンテンツに基づいてリッスンしscrollViewDidEndZooming:withView:atScale:、必要に応じてアンチエイリアスなどを実行します

試してみることにした場合は、どのように機能するかをお知らせください。最終的にこれを機能させる方法を知りたいです。さらに良いことに、それを github に投稿してください。

score 1 · Accepted Answer

ネイティブのPhotosアプリをいじってみましたが、単一のUIScrollViewを使用していると自信を持って言えると思います。景品はこれです：画像を拡大し、左または右に引っ張ります。次または前の写真が表示されます。強く引っ張ると、1.0fズームで次の写真にページングすることもできます。裏返すと、前にズームした写真も1.0fズームに戻ります。

これは間違っています。ネストされたスクロールビューを使用していて、まったく同じ効果が得られます。何らかのメモリ管理スキームを使用している場合（使用を開始する必要がありました...私のページ番号はかなり高いです（2つのscrollViewでそれぞれ約50））、ページをトリガーするものと同様のメカニズムを使用できますロード/アンロードして、現在のページから-1ページと+1ページのズームリセットをトリガーします。

前の写真が消えるとすぐに、アップルがこれを引き立たせているのではないかと思います。

私が理解していないのは、ページ間のスムーズなスクロールを実現する方法です。移行の瞬間には常に非常に短いハングがあります。わからない。私はそれを修正することにかなり深く関わっています-NSInvocationOperationsが私の最初の停止でした、それから私はページビュー（それらの画像ビューを保持します）のために再利用可能なビューキューを作りました...それでもこれはひどいハングです。

NSOperationQueueを1つだけ実行していて、同時操作の最大数をいじってみました。私の考えでは、メインスレッドは、競合するキューによって詰まっている、または1つのキューでさえ、多くのことを実行しようとしている...それでも、ハングしている。

それが問題だった場合に備えて、私は自分のメディアの超低品質バージョンを作成しようとさえしました。各画像の重量は約10kです（これらはjpegです、気を付けてください）...あなたはそれを推測しました。ハングはまだそこにあります。

以前に行ったことを実行し、Three20のTTPhotoViewControllerを使用することをほぼ決心しました。私はそのコードを数時間泳いで過ごしました、そしてそれは常に素晴らしい教育です。しかし、この時点で、私は本当にこのハングがどこから来ているのかを知りたいと思っています。そうすれば、眠れない時間を、脳の沸騰が少ないことを考えて過ごすことができます。