コア データ エントリが collectionView に表示され、1 2 3 ... n から並べ替えられています。ユーザーが最初の n をめくると、エントリの新しいバッチが追加されます。データは、Web サーバーから取得した JSON 応答から構築されます。
フェッチ要求の最初のエントリはデータソース デリゲートを介してセル 0 に関連付けられているため、コレクション ビューの下部に新しいバッチを追加することはできません。セル 0 から追加すると、古いセルの内容が新しいものに置き換えられます。つまり、ページ全体が新しいものに置き換えられたように見え、ユーザーが見ていたデータが新しいエントリの数だけ相殺されます。バッチが大きい場合は、単純に埋められます。さらに、セル 0 から更新を行うと、すべてのエントリが表示されるため、時間とメモリが必要になります。私が検討したいくつかのオプションがあります：
1) data-redorder、つまり、フェッチ結果を 1 2 3 4 ... n として取得する代わりに、逆の n ... 3 2 1 が必要です (逆順ソートを使用したフェッチとは関係ありません)。フェッチ要求。私はそれが可能かどうかわかりませんか？UICollectionViewDataSourceデリゲートに提示される前に、フェッチ結果を並べ替えることができるCDの落とし穴はありますか?
2)「collectionView cellForItemAtIndexPath:」でインデックス パス/viewCell の関連付けを変更し、(numberOfItemsInSection - IndexPath.Item) を使用します。ビューでエントリを削除/更新できるため、いくつかのエッジケースが作成されます (したがって、numberOfItemsInSection が変更されます)。できれば避けたいので…。
3) セル 0 からの新しいデータの追加は、説明した理由により除外されました。解決策があるかもしれません: ビュー オフセットを設定して満足のいく結果を達成した人はいますか? たとえば、20 個の新しいエントリが追加された場合、セル 0 のコンテンツはセル 20 に移動されます。したがって、View Controller にセル 20 以降を表示するように指示するだけです。予想される画像の反転や副作用はありますか?
4) 大量のデータをダウンロードし、組み込みのコア データ フォールト メカニズムを使用するだけです。しかし、それは最適ではありません。ダウンロードする必要がある正確な量がわからないためです (ユーザーによって異なります)。また、最初の要求 (JSON + Core Data) に時間がかかりすぎる可能性があります。とにかく、遅延フェッチがここにあるのはそのためです。
同じ問題に直面している誰かが共有できるアドバイスはありますか?
ありがとう ！