有没有办法使用startManagingCursor（）服务，而不是活动中，具有相同的结果（如这里）？

更具体地讲，我想基于服务的生命周期管理给定游标的生命周期。例如，当服务被破坏时，它会自动调用停用（）在给定的光标。此外，在创建服务时/再次启动，它将调用重新查询（）方法。

是否可行通过使用其他 在实施适当的方法 Service.class？ 是不是在一些其他的方式是否可行？ 或者是毫无意义可言？ 解决方案   

有没有办法使用startManagingCursor（）服务，而不是活动中，具有相同的结果。

没有，不好意思。

  

通过使用Service.class实施的其他适当的方法是否可行？

没有。

  

难道是一些其他的方式是否可行？

欢迎您来写自己的支持code做任何你想要的。我怀疑你可以实现你追求的东西，虽然。

  

或者是毫无意义可言？

恕我直言，是的。有一个光标时，被破坏的服务是不是一个坏主意自动关闭。然而，在的概念停用（） / 重新查询（）变得毫无意义，我的服务。这也是不可能的一部分，你有没有地方放了停用光标将被拾起你的服务的一些未来的化身。

Is there a way to use the startManagingCursor() within a service instead of an activity, with the same results (as shown here)?

More specifically, i would like to manage a given Cursor's lifecycle based on a service's lifecycle. For example, when the service is destroyed, it will automatically call deactivate() on the given Cursor. Also, when the service is created/starts again, it will call requery() method.

Is it feasible by using an other appropriate method implemented in the Service.class? Is it feasible in some other way? Or, is it pointless at all?

解决方案

Is there a way to use the startManagingCursor() within a service instead of an activity, with the same results

No, sorry.

Is it feasible by using an other appropriate method implemented in the Service.class?

No.

Is it feasible in some other way?

You are welcome to write your own support code to do whatever you want. I doubt you can implement what you're seeking, though.

Or, is it pointless at all?

IMHO, yes. Having a Cursor be automatically closed when the service is destroyed is not a bad idea. However, the notion of the deactivate()/requery() makes little sense to me in a service. This is also the impossible part, in that you have no place to put the deactivated Cursor that will be picked up by some future incarnation of your service.