您想在您的 Android 应用程序中集成 POJO 或基于 Cursor 的库吗？
我的公司想要发布一个 Android 库，以便其他人可以轻松地将我们的内容集成到他们的自定义应用程序中。
现在我仍然很不确定我应该如何提供内容。现在我正在使用 POJO 来提供项目中的数据。
我正在关注辩论“POJO 与游标”，结果支持游标。我还看到 一个示例，其中有人将解析的资源存储在 SQLLite-DB 中，并稍后通过游标访问它。
我知道 Cursors 与 POJO 相比有很多优点。但是，当您需要实现一个库时，您想搞乱光标吗？你们中的一些人可能也写过这样的库。你用了什么以及为什么？
其他库是如何做到这一点的...
响应格式：服务器响应是一个JSON字符串。 SDK 提供了 Util.parseJson() 方法将其转换为 JSONObject，可以检查和访问其字段和值。
My company wants to publish a library for android, so that other people can integrate our content easily in their custom apps.
Now I am still very uncertain how I should provide the content. Right now I am using POJOs to provide the data in my project.
I was following the debate "POJOs vs. Cursors" which turned out in favor of Cursors. I also have seen an example where somebody stores the parsed resource in a SQLLite-DB and accesses it later through Cursors.
I know that Cursors have many advantages compared to POJOs. But would you like to mess with cursors when you need to implement a library? Some of you guys might have written such libs as well. What did you use and why?
How other libs are doing it...
Response format: The server response is a JSON string. The SDK provides a Util.parseJson() method to convert this to a JSONObject, whose fields and values can be inspected and accessed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们在上一个项目中使用了 Cursor 方法，发现它相当麻烦。特别是必须检查游标中是否确实存在某些内容，对其进行迭代，找到正确的值索引，正确关闭它......这不是我喜欢一遍又一遍地做的事情。特别是整个索引的东西往往很容易损坏，特别是因为如果您实际上使用投影，则无法为其定义常量。
一个好的方法可能是使用 Cursor 支持的 POJO，至少在集合方面是这样。这样就可以按需读取数据。不过，您仍然需要找到一种合理的方法来关闭光标。
如果是单个对象，我会说让投影见鬼去吧，然后将所有内容都转储到 POJO 中。
We used the Cursor approach in our last project, and found it quite cumbersome. Especially having to check whether there's actually something in the Cursor, iterating over it, finding the right indices for values, closing it properly.. not something I like to do over and over again. Especially the whole index stuff tends to break quite easily, especially since you can't define constants for it if you're actually making use of projections.
A good approach would probably be to use Cursor backed POJOs, at least when it comes to collections. That way the data could be read on demand. You still would have to find a sensible way to close the cursor then, though.
In case of single objects, I say to hell with projections and just dump everything it into a POJO.