是否每个应用程序都允许用户输入使用核心数据构建的数据？
我构建了一个“杂货列表”类型的表格视图应用程序，您可以在其中命名列表，然后在详细信息视图中将项目添加到列表。简单的。
我不明白的是，基于 iPhone 开发书籍，该示例使用字典将数据保存到 plist 中。
我了解到它可以在模拟器上工作，但不能在设备上工作，因为数据保存到应用程序包而不是文档目录（这对我来说是新的！）
在设备上，该应用程序工作得很好，除了 - 它不会保留数据。
core data 或 sqlite 是唯一的解决方案吗？
每个允许用户输入数据的应用程序都是用核心数据构建的吗？
Is every app that allows users to input data built with core data?
I've built a "grocery list" type of table view app where you name the list and then in a detail view add items to the list. Simple.
What I don't get is this, based on an iphone development book the example saves the data to a plist using dictionaries.
I've learned that it works on the simulator but not the device because the data is saved to the application bundle not the document directory (which was new to me!)
On the device the app works great except-it won't HOLD the data.
Is core data or sqlite the only solution?
Is every app that allows users to input data built with core data?
发布评论
评论（4）
请注意，您提出的问题是不正确的，因为它假设 CoreData 与 SQLite 绑定在一起并且是 plist 的替代品。
CoreData 是对象生命周期和图形管理的框架。它提供常见任务的实现，例如更改跟踪和传播、一致性实施、数据验证等。
CoreData 框架与对象持久层分离，可以使用不同的序列化实现，包括 SQLite 和 XML (plist)。
有关更多详细信息，请阅读 核心数据编程 - 持久存储功能。
是否应该使用 CoreData 的决定应基于您是否需要它提供的任何功能。如果您需要序列化简单的对象图，而没有一致性要求，则可以使用标准 NSDictionary 在任何应用程序可写文件夹中的简单 plist 文件中序列化数据。否则，请使用 CoreData，并根据要存储的数据类型选择适当的持久存储。
Note that your question as posed is incorrect, as it assumes that CoreData is tied to SQLite and is an alternative to plists.
CoreData is a framework for object lifecycle and graph management. It provides implementation of common tasks like changes tracking and propagation, consistency enforcement, data validation and so on.
The CoreData framework is a separate from the object persistence layer and can use different serialization implementations, including SQLite and XML (plists).
For more details, read Core Data Programming - Persistent Store Features.
The decision whether you should use CoreData should be based on whether you need any of the features it provides. If you need to serialize simple object graphs, without consistency requirements, you can use standard NSDictionary to serialize your data in a simple plist file in any of the application-writable folders. Otherwise, use CoreData, and choose the proper persistent store based on the type of data you will be storing.
从我在互联网上看到的情况来看，您可以使用 Core Data（它为您提供 SQLite、atomic 和 XML 选项），您可以使用 NSKeyedArchivers 和 NSKeyedUnarchivers (http://www.vimeo.com/1454094），或者您可以将数据存储在本地应用程序文件夹中（可能使用序列化方法）。看起来核心数据是最好的解决方案，但实施起来更复杂。对于一个简单的应用程序（如您的应用程序），我认为序列化数据并将其存储在本地应用程序目录中将是完美的。
From what I've seen around the internet, you can use Core Data (which gives you the options of SQLite, atomic, and XML), you can use NSKeyedArchivers and NSKeyedUnarchivers (http://www.vimeo.com/1454094) or you can store the data inside the local application folder (possibly using a serialization method). It looks like Core data is the best solution, but a more complex one to implement. For a simple app, as yours is, I think serializing data and storing it in the local app directory would be perfect.
我很惊讶你的书展示了一个将用户数据写入应用程序包的示例。事实上，我有点惊讶这是可能的。
您应该能够将数据写入 NSDictionary （或 NSMutableDictionary），然后使用 -writeToFile:atomically 将其写入应用程序的文档目录：
使用 -initWithContentsOfFile: 读回数据也应该很简单。
对于刚刚入门的人，我建议保持简单。使用 NSDictionary 非常简单，尽管您必须管理列表列表以及如何命名存储在 Documents 目录中的列表等内容。
最终，使用 Core Data 可能是更好的方法。它提供了更大的灵活性和更强大的功能 - 但与以往一样，这些优势是有代价的。
I am surprised that your book is showing an example where user data is written to the app bundle. Actually, I'm a little surprised that that is even possible.
You should be able to write your data to an NSDictionary (or NSMutableDictionary) and then write that to your app's Documents directory, using -writeToFile:atomically:
Reading data back in should also be straightforward, using -initWithContentsOfFile:.
For someone just getting started, I would recommend keeping it simple. Working NSDictionary is very simple, though you have to manage things like the list of lists and how to name lists that are stored in Documents directory, etc.
Ultimately, using Core Data would probably be a better approach. It offers more flexibility and more power - but, as ever, those advantages come at a cost.
您的问题对于社区来说非常重要
您问的是一个战略问题：我何时使用哪种技术？
核心数据最适合基于列表的应用程序的日常工作。核心数据的构建是为了镜像数据的存储，类似于数据库的工作方式。 Core Data 最好地支持关系结构、排序、键索引和其他基于行的属性。
属性列表 (*.plist) 最适合对关键环境设置进行一次性更新。例如，用户可以选择通过 IOS 设置应用程序设置 .plist 属性。因此，密码、帐户设置、电子邮件地址和配置选项都可以在这里很好地设置。此类数据与频繁更新的事务性数据有很大不同。
XML 持久性 与 .plist 密切相关，因为属性列表（或 .plist）本身就是一个 xml 文件。因此，您可以下载 xml 数据流，然后使用与您相同的编程规则在您的应用程序中使用它，调整属性列表。因此，从 Web 接收 xml 数据或上传此类列表可以很好地映射到 xml 持久性。
AWS 还提出了 AWS-Persistence 库，以支持将您的核心数据集合与其在线数据库同步。这可以通过以下方式提供帮助：1）让用户通过 Core Data 在本地填充数据，然后惰性/机会主义地上传列表。出于您的目的（杂货购物清单），这可以为用户提供即时性，同时为您的服务器提供有趣的大数据机会（分析用户交易、提供建议、销售广告等）。
希望这能让未来的访问者利用 IOS 提供的财富——和平！
Your question is very important to the community in the respect that
you are asking a strategic question: which technology do I use, when?
Core Data is best for the day-to-day work of a list-based app. Core data is built to mirror the storage of data, similar to how databases work. Relational structures, sorting, key indexing and other row-based attributes are best supported by Core Data.
Property Lists (*.plist) is best suited to one-time updates to critical environmental settings. The user, for example, can optionally set .plist attributes through IOS Settings app. So passwords, account settings, email addresses, and configuration options can be set here nicely. This kind of data is very different from frequently-updated, transactional data.
XML Persistence is closely related to .plist, in that the property list (or .plist) is an xml file in itself. Hence, you could download a stream of xml data, then use it in your app using the same programming rubric as you would, adjusting a property list. Hence, receiving xml data from the web, or uploading such a list, maps nicely to xml persistence.
AWS also proposed the AWS-Persistence library, to support synchronizing your core data collections with their online databases. This could provide helpful by 1) having a user populate data locally via Core Data, then lazily/opportunistically uploading the list. For your purposes (grocery shopping list), this could provide immediacy to the user, while giving your server an interesting big-data opportunity (analyze user transactions, provide recommendations, sell ads, etc).
Hope this gets future visitors tapping into the wealth of what IOS provides -- peace!