问题描述
要实现我的应用程序，接着拉尔斯·沃格尔教程的数据库访问，但我很困惑的几件事情...
To implement database access in my application I followed Lars Vogel tutorial, but I'm very confused about a couple of things...
1）每次调用到 fetchTodo 一个新的光标将被创建并返回。离开previous光标垃圾收集器。所以，如果我不使用 startManagingCursor 甚至 CursorLoader 对于这个问题，我应该叫 .close（）上的光标，当我用它做？外 fetchTodo 当然范围，例如：
1) Every time a call is made to fetchTodo a new cursor will be created and returned. Leaving the previous cursor for the garbage collector. So, if I don't use startManagingCursor or even the CursorLoader for that matter, should I call a .close() on the cursor when I'm done with it ? Outside of fetchTodo scope of course, example:
Cursor cursor = mNotesAdapter.fetchTodo();
// do something...
cursor.close();
我做这个光标，新的将在接下来的创建取，我应该关闭它这样的话还是应该把它留给垃圾回收器？虽然我觉得我说的是两件事情完全不同的...点是，我应该关闭它像上面与否的例子？
I'm done with this cursor and new one will be created on the next fetch, should I close it like this then or should I leave it for the garbage collector? Although I think I'm talking about 2 things entirely different... Point being, should I close it like in the example above or not?
2） 光标也有 .deactivate（）方法和文档说，它使用较少的资源（比主动游标）。正是时候，我应该使用它？例如，在我的应用程序，我有一个 ListActivity 这是通过 SimpleCursorAdapter （在code初始化填充这只是调用一次）。正在使用的游标是一个类的成员变量，因为我需要它用于填充列表中的方法之外。我需要它来重新查询数据库时的东西从它删除。但直到一个记录被删除，这是用户操作，并可能需要一段时间才能发生，我应该停用光标在此期间？因为它会活跃起来，当我 .requery（）再打电话。或 SimpleCursorAdapter 会停止工作，因为游标不活跃？
2) Cursor also has a .deactivate() method and the documentation says it uses less resources (than active cursors). When exactly should I use this? For instance, in my app, I have a ListActivity which is populated through a SimpleCursorAdapter (the code initialization for this is only called once). The cursor being used is a class member variable, because I need it outside the method that populates the list. I need it to requery the database when something is deleted from it. But until a record is deleted, which is a user action and may take a while to happen, should I deactivate the cursor in the meantime? Cause it will be active again when I call .requery() again. Or the SimpleCursorAdapter is going to stop working because the cursor is not active?
编辑：我只是测试这一个，发现我不能叫关闭（）设置光标适配器之后。该列表将是空的，如果游标不活跃，因此它需要保持活跃，只要显示ListActivity。最后，我们应该让 StartManagingCursor 处理它呢。还是新的 CursorLoader 。
I just tested this one and found out that I can't call deactivate() after setting up the cursor adapter. The list will be empty if the cursor is not active, so it needs to remain active for as long as the ListActivity is displayed. In the end, we should just let StartManagingCursor handle it then. Or the new CursorLoader.
3）我知道 startManagingCursor / stopManagingCursor 是德precated但我不针对蜂窝（至少暂时），我不想处理新的 CursorLoader 现在。但在上面的教程中， startManagingCursor 到处使用，但 stopManagingCursor 永远不会被调用一次。为什么不呢？难道Android的处理，在它自己的方式吗？任何情况下，我应该叫 stopManagingCursor ？
3) I know that startManagingCursor/stopManagingCursor are deprecated but I'm not targeting Honeycomb (at least for the time being) and I don't want to deal with the new CursorLoader for now. But in the tutorial above, startManagingCursor is used everywhere, but stopManagingCursor is never called once. Why not? Does Android deals with that in it's own way? Any situation I should call stopManagingCursor?
推荐答案
编辑：更新的答案，以反映最新的问题1：
Updated answer to reflect updated question 1:
1）每次调用了fetchTodo一个新的光标将被创建 并返回。离开previous光标垃圾收集器。 所以，如果我不使用startManagingCursor甚至CursorLoader的 这个问题，我要呼吁光标.close（）时，我有我做的 它？
是的，你一定要既讲的Android为 startManagingCursor（），使用 LoaderManager / CursorLoader 或关闭（）它自己。不这样做将导致内存泄漏，GC将不会帮助，由于还有的光标后面本地资源（例如文件句柄到数据库）。
Yes, you should definitely either tell Android to startManagingCursor(), use LoaderManager/CursorLoader or close() it yourself. Not doing so will leak memory, the GC won't help with that as there's native resources behind the Cursor (e.g. file handles to the database).
2）光标也有.deactive（）方法和文档说它 使用较少的资源（比主动游标）。当我究竟应该使用 本？ ......
修改以其他读者：在OP找到了答案，并把它贴在了他的问题。下面仍持有：
EDIT to other readers: The OP found an answer and posted it in his question. The following still holds:
我从来没有使用<$c$c>deactivate() （有没有未激活状态（）），也许别人可以解释这一点。如果你想真正无痛重新查询/更新，请检查出 LoaderManager 框架 - 它不仅为蜂窝：使用COMPAT库，您可以使用 LoaderManager （和片段）下降到Android 1.6。它不仅是少code为你写的，但它完全卸载这些东西到Android，远远超过了 startManagingCursor（）。
I've never used deactivate() (there's no deactive()), maybe someone else can explain this. If you want really painless requery/updates, do check out the LoaderManager framework -- it's not only for Honeycomb: using the compat library you can use LoaderManager (and Fragments) down to Android 1.6. Not only is it less code for you to write, but it completely offloads these things to Android, much more so than startManagingCursor().
EDIT2：在一些注意事项 LoaderManager
Some notes on LoaderManager
有上developer.android.com LoaderManager 教程，但这些都是相当......复杂，很难在第一时间了解最喜欢的教程那里。我也只好掏了很多，最好的所有功能于一身的一站式我发现迄今是http://mobile.tutsplus.com/tutorials/android/android-sdk_loading-data_cursorloader/ （加上所有的javadoc和compat的lib中源，你可以找到）---的方式 LoaderManager 的工作原理是非常相似的（现在也去precated由 DialogFragment ）管理的对话与 onCreateDialog ，在prepareDialog 方法，你只要告诉机器人显示对话框＃123，然后Android把你的code与ID;相同的装载机：负载装载机＃123，在 onCreateLoader的Android电话（）
There are LoaderManager tutorials on developer.android.com but these are quite... complex and hard to understand the first time like most of the tutorials there. I also had to dig a lot, the best all-in-one stop I found so far is http://mobile.tutsplus.com/tutorials/android/android-sdk_loading-data_cursorloader/ (plus all the javadocs and compat lib source you can find) --- the way LoaderManager works is very similar to the (now also deprecated, replaced by DialogFragment) managed dialogs with their onCreateDialog, onPrepareDialog methods where you just tell Android to "show dialog #123" and then Android calls your code with that ID; same for loaders: "load loader #123", Android calls on onCreateLoader().
唯一明显的缺点是初期，即 LoaderManager 在很大程度上依赖于的ContentProvider 框架，有些人似乎真的不喜欢这一点。当然，这是额外的学习和code，但一旦你有一个的ContentProvider 为您自己的数据（即使只使用私人在您的应用程序），所有的数据到-view bindng与 CursorLoader 一件轻而易举的事。恕我直言，有滚动自己的内容提供者和实际执行之间的差别不大的的ContentProvider - 不过这只是我的极具争议性的意见：）
The only obvious drawback is initially, that LoaderManager relies heavily on the ContentProvider framework and some people seem to really dislike that. Sure, it's additional learning and code, but once you have a ContentProvider for your own data (even if only used privately in your app), all the data-to-view bindng is a breeze with CursorLoader. IMHO, there's little difference between rolling your own "content provider" and actually implementing the ContentProvider -- but this is just my highly controversial opinion :)
3）我知道，startManagingCursor / stopManagingCursor是德precated 但我不针对蜂窝（至少暂时），我 不想处理新的CursorLoader现在。但在 上面的教程，startManagingCursor到处使用，但 stopManagingCursor不会被调用一次。为什么不呢？难道Android的交易 与在它自己的方式吗？任何情况下，我应该叫 stopManagingCursor？
在你调用 startManagingCursor（）的光标不再是你的问题。 Android将采取关闭游标时，你的活动被摧毁的护理（用户离开，方向改变，...）。有没有必要来匹配呼叫 startManagingCursor（）通过调用 stopManagingCursor（） - 你平时不要吨要承担管理光标再次，一旦你已经摆脱了它的负担。
Once you call startManagingCursor() the Cursor is no longer your problem. Android will take care of closing the Cursor when your Activity gets destroyed (user navigates away, orientation change, ...). There's no need to match a call to startManagingCursor() with a call to stopManagingCursor() -- you usually don't want to take on the burden of managing a Cursor again once you've gotten rid of it.
这篇关于关于Android中的SQLite数据库游标几个问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！