什么是NSUserDefaults

NSUserDefaults的持久化本体是一个plist.内存单例是一个操作类似NSDictionary的类。 而NSUserDefaults的出现我想是因为在每一个程序当中。我们都会设定一些选项。比如桌面壁纸、声音大小、提醒日期等，我们希望就算App关闭以后。我们再次打开的时候还在的东西。但是它并不适合存储App中关键的内容和用户自己产生的大量数据。 大量数据应该用更加合理的方式去做持久化(Document or Core Data).

开发支持iCloud的上半部分前期准备

• 需要申请一个开发者的帐号。理论上iOS和Mac OSX的都OK。考虑到我只有iOS的情况下，我的文章里面的例子默认只是iOS的。

• 你需要一台iOS设备，并且iOS版本必须大于等于5.最好大于等于6. 最最好大于等于7。

• Xcode不用说至少是MAS里面最新的

• 然后去建立App Bundle ID的页面去把iCloud支持打开。

• bundle id需要生成带你测试设备的证书

(PS:截图太累了 换成文章描述)

这样才能算iCloud的前期工作做完了一半。

以下涉及到NDA内容请自行屏蔽

什么是iCloud

iCloud是苹果公司提供的云服务的总称。每一个拥有Apple ID的用户都拥有5G大小的空间使用权。用户可以使用iCloud的空间来进行数据的备份，联系人备份，照片备份，应用备份等。好处就是当你有多台设备或者是换新的设备的时候。可以有无差别的体验。

对于开发者来说，iCloud相当于提供了一种官方形式的云端存储形式。帮助你的App实现所谓理想的状态。不论用户在什么设备打开App。 里面的数据，设置，形状，大小。都跟他上次打开的一模一样。这样你的App会给你的用户非一般的体验。

开发慎用iCloud

上一段说了iCloud的优点，其实是接近意淫中的理想状态。我以近一年的血泪史告诫，初级开发者，应该避免使用iCloud。中高级开发者视项目规划内容酌情使用。如果能有其他方案替代iCloud，建议优先使用其他方案。

初级开发者: iCloud的三种存储方式 Key-Value， Documents， Core Data都是在之前已有的框架上进行扩展的高级接口。换言之，你应该先具备了这三种技术的基本知识再开始考虑学习iCloud。 iCloud + Key-Value对应的基础是NSUserDefaults。 iCloud + Documents对应的基础是使用文档进行数据存储(NSFileManager,NSFileCoordinator,NSFileWrapper,NSCoding等一系列持久化数据存储到文件的问题). iCloud + Core Data的对应基础就是Core Data。本来是强烈建议如果没有这些基础的人不要直接来学习iCloud的。但是谁都是一步一步走过来的，如果要用到iCloud的某一种方式。建议先把基础的持久化方式原理弄懂了，在看iCloud的部分。不然学习门槛的过高，会使得进度无法按时推进。

中高级开发者：如果是已经用过Key-Value，Documents，Core Data的。应该会很快能明白iCloud的原理。 而进行开发。但是值得注意的是，iCloud的使用和调试会非常的消耗时间和精力。并且和你的当前网络状态息息相关。然后会出现各种诡异的情况。这个时候你都需要淡定很超级的耐心。去找到这些坑，然后慢慢的积累经验去绕过这些坑。（在这里先挖坑，后面在慢慢写我的一些使用经验）

前言

通过Google分析来看blog的访问统计。发现评价阅读时间也就一分钟不到。但是之前都习惯性写长篇大论。这次换一种方式来写blog。尽量写短一些的小一些的题目。使得更新数量上去。

这次我来说说怎么设置Tab来提高在xCode的工作效率。

我是如何使用Tab来提高效率的

xCode的Tab是什么

诺，就是这一个东西。

使用过各种浏览器的你一定不会陌生。对在xCode里面我们也可以开出多个页面。而且每一个页面的状态是单独保存的。

iOS进行单元测试OCUnit+xctool

单元测试

什么是单元测试

wiki解释

简单说来就是为你的方法多专门写一个测试函数。以保证你的方法在不停的修改开发中。保持正确。如果出错，第一时间让你知道，这样从最小单位开始监控来保证软件的质量。

我为什么要单元测试

其实要开始写单元测试的原因是，由于我的原因格志的存储逻辑一直有问题。 一个是代码写的比较搓，一个是修改存储的逻辑的话。影响面比较大。可能修复了一个bug而引入了未知的多个bug。为了Sumi早日达到国际化大厂的标准。决定上单元测试于格志。其实最根本的目的还是想要项目变的更加可靠。

单元测试的一般方法

关于测试的书，一搜就一大把。都有高深的理论和方法来指导怎么写单元测试的方法。我觉得嘛不用搞了这么复杂。 无非就3种时候会去想写测试：

1. 代码完成以后
2. 开始写代码之前
3. 修复了一个bug以后

第一种是完成了代码，恩我要测试一下我写的这些方法可靠不可靠。那这时候可以写测试。

第二种一个著名的方法论TDD。主要思想就是在写代码之前，就全部设计好借口。函数名字什么的。然后在写能通过测试的函数。

第三种就是发现了bug，我修复了这个bug。为了确保修复是成功的。那就写个测试吧。

我觉得啊，着三种都没有什么好或差。能写测试的少年都是好少年。何必这么在意什么时候去写呢。

一个完整的测试类组成像下图

在一开始可能测试方法里面需要一些上下文环境。这些可以在Setup里面去完成。然后才可是执行自己写的测试方法。 然后测试结束以后，可能产生了一些垃圾数据文件什么的。这时候你可以在TearDown方法里面把他们处理掉。

以上大部分都是我自己的粗浅理解，如果你需要更多关于单元测试请阅读更加系统专业的书籍。

CoreData (四)

监听NSFetchedResultsController

之前说过, NSFetchedResultsController是有两个重要的功能。

第一:NSFetchedResultsController是作用在Core Data上的,通过NSFetchRequest来查询Core Data里面的数据.可以返回按照组分好的数据.这样便于UITableView来显示.

第二:但Model改变的时候NSFetchedResultsController能及时的发出通知.准确的说,应该是当NSManagedObjectContext发生改变的时候,NSFetchedResultsController能知道这些变化,然后发出通知出来.以便UITableview能及时的更新.

上一篇写了第一点. 现在写第二点.

CoreData (三)

NSFetchedResultsController

什么是NSFetchedResultsController

NSFetchedResultsController是一个让人爱恨交加的一个类。如果使用得当，NSFetchedResultsController能帮组减少很多代码。如果使用不当，整个App就随时崩溃。

NSFetchedResultsController我觉得最初的设计应该是为了配合UITableView来使用的。因为UITableView在iOS的应用App中出场次数实在是太高了.而且UITableView是重要的数据展示View,所以需要频繁的向Model去请求数据,但是根据MVC来说,V不应该直接跟M联系的.这样就在Core Data下面出现了一个C–NSFetchedResultsController来把V和M协调起来. NSFetchedResultsController就是这个C.

NSFetchedResultsController是有两个重要的功能。

第一:NSFetchedResultsController是作用在Core Data上的,通过NSFetchRequest来查询Core Data里面的数据.可以返回按照组分好的数据.这样便于UITableView来显示.

第二:但Modle改变的时候NSFetchedResultsController能及时的发出通知.准确的说,应该是当NSManagedObjectContext发生改变的时候,NSFetchedResultsController能知道这些变化,然后发出通知出来.以便UITableview能及时的更新.

UITableView简单解析

序

UITableView是在iOS开发中，展示大量内容的首选。我个人认为的原有有一下几点：

1. UITableView的展现形式是为移动设备专门设计过的。有较好的人机交互体验。
2. 从技术角度来说UITableView具有重用和延迟加载等特性。如果使用恰当。可以获得一个App流畅的用户体验。

这样，使得UITableView在iOS App中随处可见。

原生应用

一些有名的App.图片信息较老

包括游戏

这些都说明UITableView在一个App中其实是一个很常用的控件。我应该好好的学习它。

Core Data (二)

序

上次只是说了三个Core Data栈基本类。这次准备介绍一下常用的类。

NSManagedObject

Core Data是一次底层数据封装成面向对象的技术。最直接的表现就是在SQLite里面的一条记录在Core Data里面的表现是一个NSManagedObject对象。因此我们的增删改查都是基于操作对象的。恩这里多说一句，NSManagedObject是相对NSManagedObjectContext里面是唯一的。而真实的应用情况可能是NSManagedObjectContext会有多个。而NSManagedObjectContext线程不是安全的，所以可能有你多个NSManagedObjectContext里面各自有指向同一条数据的不同的NSManagedObject。这个情况需要你的程序设计和逻辑上去解决。暂时不讨论。

Core Data (一)

序

恩，用Core Data也有一段时间了。大大小小的坑也都坑过了。重来没有认真的记录一次。这次需要好好的理一理Core Data。就当一次绝好的机会记录下来。也为了自己加深认识。

为什么要用Core Data

CoreData的学习是需要一定成本的。以至于我认识的人很少在用，大家要不就是用一个FMDB。或者做的App是一个已有的Web的延伸，数据直接用Web端的Api取回来就好了。

我们要用Core Data的理由有以下几点：

1. Core Data是对底层存储的一次封装。封装了以后就变成ORM的框架。这样就变成操作对象。Core Data自己去进行数据的保存。
2. 使用Core Data而不是FMDB，让整个程序架构更加的面向对象。
3. Core Data仅仅使用了Objective-C和Core Foundation，你不必去加入一些第三方的库。
4. Core Data是Apple的原生技术。每年的WWDC都能看到新特性的加入和讲授。
5. Core Data支持iCloud。而使用iCloud的App。Apple推荐的可能性增加。
6. 有了iCloud为以后Apple的全平台数据共享打下基础

所以，没有理由拒绝使用Core Data做为你App的持久化。Core Data应该是一个跟Apple混的第一选择。