3

startManagingCursorを廃止する理由は何ですか？

私のシンプルなアプリには、DBからのデータのリストを含むテーブルビューがあります。だから、私が今onCreateに持っているもの：

 final Cursor cursor = getDataFromDB();
 startManagingCursor(cursor);
 setListAdapter(new CursorAdapter(cursor));

そしてそれはそれです、そして私は他に何もする必要はありません...

ただし、startManagingCursorは現在非推奨であり、LoaderCallbacksを実装し、onCreateLoader、onLoadFinished、onLoaderResetをオーバーライドし、DBにContentProviderを作成する必要があります。しかし、私はこのすべてのスタッフを必要とせず、DBから数行の情報を取得する必要があります。どうなる？なぜアンドロイドはそれをしましたか？なぜこのすべてのスタッフを実装する必要があるのですか？

4

2 に答える 2

5

そうは言っても、Androidで「非推奨」とは、通常、「これを引き続きサポートしますが、より良い解決策があると考えています」という意味です。

FragmentActivityから継承する場合は、Androidサポートパッケージのローダーフレームワーク実装を使用して、Android1.6までさかのぼることができます。

確かに、APIレベル11以降でstartManagingCursor（）を使用できます。ただし、管理対象カーソルの問題（特に、メインアプリケーションスレッドでのアクティビティの再起動時にrequery（）を実行すること）は、古いバージョンと新しいバージョンのAndroidでも引き続き発生します。

出典：Android eclipse startManagingCursor非推奨ですが、古いAPIバージョンをサポートしたいですか？

于 2012-06-19T11:28:58.920 に答える
4

それが非推奨になる「理由」は、人々がContentProviderを採用することを本当に望んでいるからだと思います。これは、プッシュしているときにさらに明白になり、sでのみ機能Loadersするを提供します（個人的には名前が間違っているため、名前を付ける必要があります）CursorLoaderContentProviderContentLoader

アクティビティに含まれていたためstartManagingCursor、（例で行っているように）人々が簡単に実行できず、UIスレッドでdbクエリを実行するだけで、一時停止やANRが発生することがありました。

ContentProvidersではなくCursorsで動作する独自のCursorLoaderを作成し、それを再利用可能なクラスにして、LoaderContentProvidersを使用せずにフレームワークを使用できるようにすることができます。

これに対する私の解決策は、コンテンツプロバイダーの作成を非常に簡単な操作にする小さなフレームワークを単純に構築することでした。これにより、既存のを活用できるようになりCursorLoaderます。

于 2012-06-19T11:53:21.627 に答える