2

このコードのすべてが存在するフラグメントを実装するアクティビティがあります。コードは機密であるため、これは例を使用して説明するのが最適です。この例は、やろうとしていることと、私がテストで観察したことを反映しています

例) ローダー ID (ローダー 1、ローダー 2) を持つ 2 つの一意のローダーから 2 つの一意のオブジェクト (A、B) をフェッチする rss リーダー フラグメントがあります。

Object A: 

int[] fullArticleIdList;
List<ArticlePreview> partialArcticlePreviewList;

Object B:

List<ArticlePreview> partialArcticlePreviewList;

作成時に、オブジェクト A を取得するローダー 1 で「initloader」を呼び出します。利用可能な記事をスクロールした後、オブジェクト A から返された partialArcticlePreviewList の一番下に到達し、オブジェクト B を取得してユーザーを許可するローダー 2 の「restartloader」を使用して、さらに記事を取得します。それらを読み、すべての記事に対してこれを続けます。

これは、ユーザーがデバイスを回転させて onCreate を呼び出すまでは正常に機能します。initloader がローダー 1 で呼び出されると、ローダー 1 に接続した後、すぐに onLoadFinished にジャンプし、ローダー 1 を返します。articleIds は適切に返されますが、返される partialArcticlePreviewList は、オブジェクト B をフェッチしたローダー 2 からのものです。

ローダー マネージャーはオブジェクトのインスタンスを 1 つだけキャッシュに保持し、それを複数のローダー間で共有しますか? 広範なテスト (5 時間以上かけて問題を見つけ、Eclipse デバッガーでローダー ID/キャッシュ/アドレスを調べた) から、ローダー 1 の partialArcticlePreviewList が、ローダー 2 の partialArcticlePreviewList で受け取ったデータで上書きされたように見えます。この状況は単一のローダーにとって理想的ですが、各ローダーのキャッシュは別々になると考えていました。明らかに、ローダーの利点の 1 つは、使いやすさと、画面の回転とデータ キャッシュによる持続性ですが、暗示どおりには機能していないようです。私達'

編集: 追加するのを忘れました。互換性ライブラリ v4 を使用しています。また、ローダーのアンドロイドソースを見ても、ローダーが「mId」に対して間違ったデータを返す理由について、状況を明らかにしているようには見えませんでした。

4

1 に答える 1

3

この問題を回避するために使用された最終的な解決策は、ローダーに依存せずにデータを自分で管理することでした。

ローダーは、画面に 1 つだけをロードする場合はデータを保持するのにうまく機能しますが、ページングの場合はこのような手間がかかり、操作方法はまだよく理解されていません。結論は、それらが期待どおりに動作しなかったか、実装に問題があるということであり、より高度なユース ケースでのみ明らかになります。

データを自分で管理するために、onDestroyView ですべてを適切にクリーンアップするように注意しながら、バンドル/保持フラグメントの組み合わせを使用しています。また、ローダーがローテーション後にコールバックを実行するときに、データセットに既にデータがあるかどうかを確認するようにします。もう 1 つの方法は、シングルトン オブジェクトを使用することです。

これが将来誰かに役立つことを願っています。

于 2012-08-10T18:34:21.520 に答える