1.4.2.5. 测试(Core Data 应用程序实践指南)

  测试的方法也很简单:

  • 首先,在AppDelegate.h里面引用CoreDataHelper

    @property (strong, nonatomic, readonly)CoreDateHelper *coreDataHelper;

    ds

  • 初始化CoreDataHelper

    - (CoreDateHelper*)cdh {
        if (debug == 1) {
            NSLog(@"Running %@ ‘%@‘",self.class, NSStringFromSelector(_cmd));
        }
    
        if (!_coreDataHelper) {
            _coreDataHelper = [CoreDateHelper new];
            [_coreDataHelper setupCoreData];
        }
        return _coreDataHelper;
    }
  • 在程序转到后台或退出时保存

    [[self cdh] saveContext];

ddd

时间: 2024-12-11 00:01:35

1.4.2.5. 测试(Core Data 应用程序实践指南)的相关文章

3.2. 添加模板版本(Core Data 应用程序实践指南)

为了不像3.1那样崩溃,修改模型之前先创建新的模型版本.添加之后,会生成一个新的xcdatamodel文件,并且跟原来的内容完全一样,这有意思了,但是不要删除原来旧版的模型.旧的模型有助于把原来持久化存储区迁移到当前的模型版本. 修改程序: 选中Model.xcdatamodeld 点击Editor > Add Model Version... 点击Finish,默认将Model 2用作版本名称 如图: 注意,我们要修改新的模板,慢慢进入正题了: 注意备份程序 选择Model 2.xcdatam

3.3. 轻量级的迁移方式(Core Data 应用程序实践指南)

持久化存储协调器会试着用新版的模板打开原来的持久化存储区,但是那是旧的模板,旧的格式,当然会出错.现在要做的就是迁移现有的持久化数据区,以便跟新模型匹配. 怎么进行迁移呢? 在什么时候进行迁移? 在向NSPersistentStoreCoordinator添加存储区的时候. 那么如何添加呢? 答案是,将下列选项放到NSDictionary里传过去,就会自动完成存储区的迁移工作. 如果传给NSPersistentStoreCoordinator的NSMigratePersistentStoresA

1.4.2.4. SAVING(Core Data 应用程序实践指南)

现在,要添加一个保存修改的方法.其实很简单,就是调用持久化存储协调器的save方法. - (void)saveContext { if (debug == 1) { NSLog(@"Running %@ '%@'",self.class, NSStringFromSelector(_cmd)); } if ([_context hasChanges]) { NSError *error; if ([_context save:&error]) { NSLog(@"_c

[转]ASP.NET Core Web API 最佳实践指南

原文地址: ASP.NET-Core-Web-API-Best-Practices-Guide 转自 介绍# 当我们编写一个项目的时候,我们的主要目标是使它能如期运行,并尽可能地满足所有用户需求. 但是,你难道不认为创建一个能正常工作的项目还不够吗?同时这个项目不应该也是可维护和可读的吗? 事实证明,我们需要把更多的关注点放到我们项目的可读性和可维护性上.这背后的主要原因是我们或许不是这个项目的唯一编写者.一旦我们完成后,其他人也极有可能会加入到这里面来. 因此,我们应该把关注点放到哪里呢? 在

ASP.NET Core Web API 最佳实践指南

https://www.cnblogs.com/hippieZhou/p/11966373.html 原文地址: ASP.NET-Core-Web-API-Best-Practices-Guide 原文地址:https://www.cnblogs.com/94cool/p/12388416.html

Core Data Programming Guid

(转) 关于Persistent Stack 对象和外部数据存储,这两者之间的媒介,被整体叫做persistence stack.其中,managed object context位于栈顶,persistent object store位于栈底,中间的是persistent store coordinator. Persistent stack 实际上,是persistent store coordinator决定着这个栈.它使用了facade模式,使得栈底的多个persistent store

不再为Core Data多线程编程而头疼

by Saul Mora原文链接:http://www.cimgf.com/2011/05/04/core-data-and-threads-without-the-headache/ 我知道我曾经提到我要写一篇关于定制fetch requests的文章,然而,在我为Active Record Fetching project(现在已经改名为MagicalRecord)编写了一些代码之后,我觉得写一篇关于fetching–threading.的文章更好一些. 当大多数cocoa开发者提到Core

core data 深入解析

罗朝辉(http://blog.csdn.net/kesalin) CC 许可,转载请注明出处 Core data 是 Cocoa 中处理数据,绑定数据的关键特性,其重要性不言而喻,但也比较复杂.Core Data 相关的类比较多,初学者往往不太容易弄懂.计划用三个教程来讲解这一部分: 框架详解:讲解 Core data 框架,运作过程,设计的类: Core data应用程序示例:通过生成一个使用 Core data 的应用程序来讲解如何 在 XCode 4 中使用 Core data. 手动创

iOS Core data多线程并发访问的问题

大家都知道Core data本身并不是一个并发安全的架构:不过针对多线程访问带来的问题,Apple给出了很多指导:同时很多第三方的开发者也贡献了很多解决方法.不过最近碰到的一个问题很奇怪,觉得有一定的特殊性,与大家分享一下. 这个问题似乎在7.0.1以前的版本上并不存在:不过后来我升级版本到了7.0.4.app的模型很简单,主线程在前台对数据库进行读写,而后台线程不断地做扫描(只读).为此每个线程中各创建了一个NSManagedObjectContext. 这个模型其实有点奇怪,因为普遍的模型是