FMDB 和 UITableView
我们在 sqlite3 中有一个包含许多行的数据库。我们正在利用 SQLite3 的 FMDB 包装器在 UITableView 中显示数据。我们最好不要使用分页，因为这对于 iPhone/iPad 应用程序来说感觉不太正常。我们希望，如果必须这样做，我们可以以 400 条左右的记录的形式进行。
最好的方法是什么？有什么办法可以调用数据库吗
-(UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath`
？
即使我们做了“更多记录...”表格单元格，一旦它们达到巨大的数字会发生什么？我们必须进行双向分页吗？
处理这个问题的最佳方法是什么？
谢谢。
We have a database of many many rows in sqlite3. We are utilizing the FMDB Wrapper for SQLite3 to show data in a UITableView. It is preferred that we do not use Pagination as this doent feel very normal for an iPhone/iPad application. We were hoping that if we MUST do so we could do so in the form of 400 or so records.
What is the best way to do this? Is there any way to call the database on
-(UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath`
?
Even if we do a "More Records…" table cell, what will happen once they reach a huge number? Will we have to do 2-way pagination?
What is the best way to handle this?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这就是我所做的，使用类似的设置，UITableView 有数千行。
我有一个数组（实际上是一个 C++ stl 向量），其中数组中的每个项目都映射到 UITableView 中的一行。该数组填充了我想要显示的项目的 sqlite 记录 ID。数组占用的内存为每行 4 个字节。
cellForRowAtIndexPath 查找数组中的记录 ID，然后从 sqlite 查询单元格所需的字段。由于 SQLite 对记录 ID 列建立了索引，因此速度非常快。
我的实际上有点复杂，因为我有 TableView 部分以及 TableView 索引。但也不过分复杂。
Here's what I do, with a similar setup that has thousands of rows for the UITableView.
I have an array (actually a C++ stl vector) where each item in the array maps to a row in the UITableView. The array populated with the sqlite record ID's for the items I want to display. The memory taken by the array is 4 bytes per row.
cellForRowAtIndexPath looks up the record ID in the array, then queries from sqlite the fields I need for the cell. It's plenty fast since SQLite indexes the record ID column.
Mine is actually a bit more complicated since I have TableView sections, as well as a TableView index. But not overly more complicated.