应用开发中的用户界面与数据管理

# 应用开发中的用户界面与数据管理 ## 1. 视频显示应用的实现 在开发应用时，有时需要在视图中显示视频。实现这一功能，最简单的方式是使用Cocoa Bindings。以下是具体的操作步骤： 1. 再次打开nib文件并选择电影视图。 2. 从绑定检查器中，展开“Movie”项，使用“movie”键将其绑定到“File’s Owner”对象（“movie”键引用了你刚刚添加的属性）。 3. 保存文件，然后构建并运行项目。 运行项目后，会得到一个没有窗口的应用程序。按下特定组合键（如܆ - O）打开一个新文档并选择一个电影文件，此时会出现一个新的文档窗口，窗口底部有一组简单的控件。点击“Play”按钮，电影将在该窗口中播放。你还可以尝试其他UI操作，如调整大小、全屏显示、打开多个电影窗口等，这些操作应该都能按预期工作。 示例代码如下： ```objc *outError = [NSError errorWithDomain: QTKitErrorDomain code: QTErrorIncompatibleInput userInfo: info]; } return ( NO ); } self.movie = [[QTMovie alloc] initWithURL: url error: outError]; return ( self.movie != nil ); ``` ## 2. 数据管理与Core Data概述 处理结构化数据一直是一个复杂的话题，需要考虑多个方面，例如内存中数据的结构与永久存储中数据的结构、两者之间的转换方式，以及在不影响任何层面性能的情况下处理可能无限大的数据集的最佳方法。解决这个问题有很多不同的方法，如XML和JSON等数据格式，以及SQL数据库、Tokyo Cabinet等键值存储和CouchDB等文档存储等大规模存储引擎。它们都有自己的表示方式、API以及各自的特性和局限性。一旦你为特定的范式编写了数千行代码，之后再更改选择往往会很困难。 Core Data应运而生。它起源于NeXTstep和OpenStep操作系统的两个项目：首先是Database Kit，它提供了一个与数据库无关的编程接口，由当时流行数据库的驱动程序支持。在此基础上发展出了Enterprise Objects Framework（EOF），它是NeXT的WebObjects动态网站系统的一个组件。EOF使用新的范式进行了重建，使其更像是一个“可查询的对象存储”，而不是传统的数据库。WebObjects产品及其框架后来被移植到Java，现在仅作为主要与OS X Server工具一起分发的Java系统存在，并运行在标准的Java Server容器之上。EOF的一个重大进步是使用“faulting”系统管理不同实体之间的关系，仅在需要某个实体或其关系时才从后备存储中获取数据。 ### 2.1 Core Data框架介绍 Core Data是Apple在OS X 10.4中引入（并在iOS 3.0中移植到iOS）的框架，它是EOF的直接后代。不过，它的重点有所不同，EOF旨在与独立的数据库服务器配合使用，而Core Data的目标是将本地数据存储作为对象持久化机制，提供世界级的对象建模和生命周期管理系统。 Core Data提供了一个面向对象的实体和属性系统来建模数据，并将其与两种存储系统相结合： - **原子存储（Atomic Store）**：一次性将所有数据加载到内存中，并完全在内存中处理数据。 - **增量存储（Incremental Store）**：将数据保留在磁盘上，并根据需要逐步加载数据。 此外，它还配备了强大的缓存和查找系统，在性能和内存占用之间取得了良好的平衡，以及一个存储管理子系统，使你无论数据存储在单个文件还是多个文件中，使用一个还是多个独立模型，都能对数据有一个统一的视图。而且，这三个组件在架构上相互独立，上下文和缓存系统使用单一接口与任何数据存储进行通信，与持久化层的接口也类似地进行了定义。 Core Data API围绕几个核心类型构建，它们共同实现了上述三个接口层以及对象建模功能本身。Core Data栈的概念布局如下： ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(Object Context):::process --> B(Persistent Store Coordinator):::process B --> C(Persistent Store 1):::process B --> D(Persistent Store 2):::process B --> E(Persistent Store 3):::process F(Object Model):::process --> B G(Object):::process --> A H(Object Context):::process --> B I(Object):::process --> H ``` ### 2.2 Core Data的核心组件 - **NSManagedObjectModel**：用于实现对象建模，它表示从一个或多个对象模型定义文件加载的单个实体图。模型的实体、属性和关系由`NSEntityDescription`和`NSPropertyDescription`类定义，后者有用于属性和关系的子类：`NSAttributeDescription`和`NSRelationshipDescription`。 - **NSPersistentStore**：提供持久存储，封装了磁盘或内存中的单个存储。给定模型的存储由`NSPersistentStoreCoordinator`实例管理，该实例确定为不同实体查询哪个存储。当你创建自己的原子或增量存储时，需要子类化`NSPersistentStore`的两个提供的子类之一：`NSAtomicStore`或`NSIncrementalStore`。持久存储层决定了托管对象如何写入永久存储，因此某些类型的存储可能不会实现其他存储中可用的所有功能，但这仅在相当高级的情况下才会出现。 - **NSManagedObjectContext**：处理对象生命周期管理，实现了缓存机制和Core Data的大部分公共接口。几乎你执行的所有操作在某种程度上都会使用对象上下文。当你创建新的托管对象或查询存储时，都是通过向`NSManagedObjectContext`实例发送消息来完成的。每个托管对象都与一个单一的上下文关联，每个上下文都与一个持久存储协调器关联，而持久存储协调器又有一个定义其实体集的对象模型。 - **NSFetchRequest**：用于实例化托管对象，它包含一个谓词（如`NSPredicate`）、一些用于对结果进行排序的排序描述符，以及各种其他属性，用于根据存储和返回的对象类型微调结果集。 ### 2.3 Core Data的内置存储类型 Core Data提供了四种内置存储类型（iOS上有三种），并允许你使用原子（从OS X 10.5和iOS 3.0开始）和增量（从OS X 10.7和iOS 5开始）存储范式创建自己的存储。通过在初始化存储时向`NSPersistentStoreCoordinator`指定一个常量来选择存储类型： | 存储类型 | 描述 | 指定常量 | | ---- | ---- | ---- | | 内存存储（In - Memory Store） | 一种原子存储，不会将数据写回磁盘。如果你管理的对象图不需要在应用程序重新启动后持久化，这种类型可能适合你。 | `NSInMemoryStoreType` | | XML存储（XML Store） | 另一种原子存储，一次性将所有数据加载到内存中，并以纯文本XML格式写入永久存储。这种存储对于调试很有用，因为你可以在文本编辑器中轻松打开持久存储进行手动检查。注意，XML存储在iOS上不可用。 | `NSXMLStoreType` | | 二进制存储（Binary Store） | 以优化的二进制格式写入所有数据，以便快