1

私はiPhoneアプリを持っています。このアプリを開くと、約25000レコードを含むデータのテーブルを表示する必要があります。各レコードは、TITLEとDESCRIPTIONの2つのフィールドで構成されています。両方のフィールドが各テーブルセルに表示されます。テーブルビューもUISearchBarで完全に検索できます。

アプリケーションが起動し、このビューがロードされると、「コレクションオブジェクト」がテーブルからすべてのデータを取得し、それを「アイテムオブジェクト」にロードします。検索には両方のフィールドが必要なので、実際には水和/脱水するものは何もありません。したがって、テーブル全体がメモリ内にあります。完全な検索機能を提供するより良い方法が必要ですが、一度にメモリ内のオブジェクトの数を大幅に減らします。

何か案は？

編集：

さらに説明する必要があると思います。

私はすでにSQLiteデータベースを使用しています。私の問題は、20,000レコードをメモリにロードするのに時間がかかりすぎて、アプリケーションが遅く見えることです。

また、現在の選択のいずれかの側に100レコードしかない場合、すべてのレコード（メモリにないレコードを含む）を検索するにはどうすればよいですか？

テーブルデリゲートの提案を調べます。

4

5 に答える 5

3

すべてをメモリにロードしてそこから検索するのではなく、SQL を使用して検索する必要があります。フラットファイルのように使用している場合、データベースとはどのような点ですか?

また、多くのアプリケーションには、ビューに項目を追加するテーブル ビューの最後に「さらに読み込む」エントリがあります。

于 2009-01-29T09:03:42.143 に答える
2

おそらく、グループの他のメンバーが言っていることを明確にすることができます。

ご存知のとおり、テーブルビューには、<UITableViewDatasource>プロトコルで少なくとも2つの必須メソッドを実装するデータソースが必要です。

– tableView:cellForRowAtIndexPath:  
– tableView:numberOfRowsInSection:

現在の実装で– tableView:cellForRowAtIndexPath: は、グローバルコレクションオブジェクトから2つの文字列を取得し、それらをセル（適切に再利用されていることが望ましい）にポップして返していると思われます。

おそらくそれがすべきことは、必要に応じてデータベースからそれらのデータを取得することです。アプリとデータベースの間を仲介するクラスを実装し、たとえば、データソースとして機能しているクラス（SQLiteはLIMITキーワードとOFFSETキーワードをサポートします）に一度に100行のブロックを返します。その限られたセットに。

tableViewによって呼び出されると– tableView:cellForRowAtIndexPath:、データがローカルに保存されたブロックにあるかどうかを確認でき（現在のレコードオフセットを保存するプロパティを作成します）、そうでない場合は、次のDBへのリクエストでローカルブロックを更新します（または以前、場合によっては）100レコード。

プレスト。固定数（100）のレコードが常にメモリにあり、データソースは必要に応じてテーブルビューにデータを提供します。あなたはもっと空想を得ることができますが、それは一般的な考えです。

検索に関しては、タイトルでフリーテキスト検索を行っていると仮定して、データベースメディエーターに次のようなものを発行させます。

 'select id, title, description from yourTable where title like ?'

？をバインドします ユーザーが入力したものに応じて、適切な場所にワイルドカードを使用します（入力をサニタイズすることを忘れないでください... iPhoneアプリでSQLインジェクションを実行する可能性が非常に高いわけではありませんが、習慣やすべて... :)

明らかに、結果をフィルタリングするのではなく検索するだけの場合は、すべてを少し調整する必要がありますが、それが始まりであることを願っています。

幸運を！

于 2009-02-04T04:06:33.997 に答える
2

アプリのアーキテクチャを再考します。

覚えておかなければならないのは、iPhone はデスクトップ アプリと同じではなく、人々は通常のコンピューターのように電話を使用しないということです。iPhone は一度に何時間も使われるのではなく、何分間も使われます。20,000 件以上のエントリをスクロールしたいと思う人はいないでしょう。正直なところ、デスクトップ アプリでそれをやりたいと思う人がいるかどうかはわかりません。

代わりに、限られた数のエントリ (おそらく 100 または 200 のトップ) をロードします。次に、ユーザーにさらにロードさせます (または、必要なものを検索させます)。

于 2009-01-29T00:06:23.383 に答える
1

テーブルにデリゲートを使用してみて、必要に応じて項目のみをメモリにロードする必要があります。最初の 10 項目のみが表示されている場合、OS はそれらの項目のみを尋ねます。

レコードを SQLite データベースに保存することも検討する必要があります。検索がアクティブな場合、デリゲートは、現在の検索用語を使用して作成された SQL クエリを操作します。

于 2009-01-28T22:24:45.147 に答える
0

現在の画面の前後に50〜200程度のメモリを検索して保持し、データベースからさらに読み込まれるときにアイテムをスクロールできるようにすることをお勧めします。

編集; SQL liteも、前述のように優れたアイデアです。

于 2009-01-28T22:35:31.040 に答える