CoreData VS Realm (2016-02-23更新)

本文具有强烈的个人感情色彩,如有观看不适,请尽快关闭. 本文仅作为个人学习记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作. 如果您觉得本站对您能有帮助,您可以使用RSS方式订阅本站,这样您将能在第一时间获取本站信息.

碎碎念

OhMyStar 2 也进行了一段时日,我把持久化的方式从CoreData 换到了 Realm。有些感悟,顺手就记录一下吧。以下评论都是自己很主观的感受,无实际测试数据支持。

论 iOS 的持久化

iOS 持久化其实也没多少选择, 高端一点CoreData、Realm、FMDB、KV类(LevelDB等)。低端一些直接一个 NSArray 就写成 Plist 也能持久化下来。

在网络环境越来越快的当下和大部分应用数据都可能是网络应用,如果业务逻辑并不复杂,其实极端一点就只用写到 JSON 转 Object 就好了。而且一堆这样好用的封装,远有Mantle 近有YYModel

所以需要持久化的时候,我觉的可以慎重的评估一下需求。想明白了,后面可以节省很多事情。

本文章主要对比 Realm 和 CoreData,其他的就不涉及了。


iOS 学习笔记 (36) ReactiveCocoa 用 RACSignal 替代 Delegate

本文仅作为个人学习记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS方式订阅本站,这样您将能在第一时间获取本站信息.

开篇扯淡

最近又在看 ReactiveCocoa 了(下面用 RAC 来替代 ReactiveCocoa)。虽然依然是 hello world 级别。但是 hello world 也是可以分级别的。这次自我感觉是一个偏向中级的 hello world。

我们先来张图:

在 RAC 的文档和一些介绍 RAC 的 Keynote 资料里面我们可以看到说 RACSignal 可以来替代 Delegate、 Block Callbacks、Target Action、KVO、Notifications。

但是貌似没有一种 hello world 的方式来进行说明如何替代的。

插嘴:在中文 blog 里面见过几个写 RAC 的比较好哒。一个是limboy大大的几篇深入浅出令人叹为观止,李忠大大不但研究透彻了然后还结合自己的实战经验写成很好的文章来分享。 另一个是sunnyxx的Reactive Cocoa Tutorial系列这个系列比较偏向研究 RAC 是如何实现和工作的。

我这个人比较笨,最喜欢写 hello world。那就找时间一个一个来写呗。

写之前 Google 了一下。所以以下内容大量参考:Replacing the Objective-C “Delegate Pattern” with ReactiveCocoa。能看原文就去看看。然后忽略掉以下的 hello world 就好了。


iCloud 和 iCloud Drive

本文仅作为个人学习记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS方式订阅本站,这样您将能在第一时间获取本站信息.

开篇扯淡

  1. 好久没有写 blog 了。
  2. 最近发现很多人对 iCloud 和 iCloud Drive 有些误解。而还没有看见中文里面有一个比较正确的说法。
  3. 加上近两年来工作就是在学习 iCloud 如何使用。最近一个月做客服小弟回复了 N 个 iCloud 的问题。所以感觉还是有一些价值的。特意想记录一下。

是否升级到 iCloud Drive

在 iOS 8 刚刚上线的时候,用户更新了以后。第一次会跳出来,说需要重新升级的 iCloud Drive。因为没有更多的信息和提示,我想一个正常的用户应该都会去点击升级。结果就是导致很多使用 iCloud 这个功能的 App 数据出现问题。或者导致了设备之间的不同步。那会有很多文章在建议不要升级 iCloud Drive。所以可能会给后来升级到 iOS 8 的用户造成一定的心里作用说升级 iCloud Drive 是不可靠的。

其实根据我两年来 iCloud 的经验和测试结果。 iOS 8 的 iCloud Drive 是一个 Apple 云端的一次最重要的里程碑。 是 iCloud 这个技术在 Apple 产品系列上第一次做到了可用的状态。等了三年终于有个云的模样了。

当时不建议升级 iCloud Drive 的理由其实就两个:

  1. 对于开发者来说,由于 Apple 为了保密 iPhone 6 和 iPhone 6 Plus。 其实在9月发布会之前。 iOS 8 的 最后两个 Beta 版本是没有提供给开发者的。在能获得的最后的 Beta 版本上。 开发者使用 iCloud 依然各种莫名其妙的问题。一直到 GM 版本才变得正常。这样导致 GM 到发布正式的版本之间的时间。大部分开发者还无法把更新 iCloud 的技术及时的完善在自己的 App 里面。
  2. 另外一个是在 iOS 8 已经放出来的时候,OS X 10.10 还没有放出来。这样如果你是一个 Apple 一套的普通用户。就会导致你一些全平台使用 iCloud 技术的 App无法相互同步。所以在当时确实这样情况的普通用户应该谨慎更新。

现在11月了这两个问题随着开发者对 App 的完善和 OS X 10.10 释出。其实都不是问题了。大家可以放心大胆的升级了。


iOS笔记(35) 格志周年系列之夏令时(三) 临时花絮

本文仅作为个人学习记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS方式订阅本站,这样您将能在第一时间获取本站信息.

开篇扯淡

说曹操,曹操到。嘛当,还说总结一下时间的问题。这不blog这个系列没有写完。又爆了出一个时间相关的Bug。我只能说编程路茫茫,吾将上下求索。这次就着热乎着,来说是一个遇到了什么问题。

遇到的问题

有日本用户反馈,新版本更新以后,他日历上的时间全部乱了。而且无法写入日记。经过与用户沟通(感谢喵神onevcat的日文人肉翻译)分析得到用户使用和历(日本日历)。然后debug进去果然日期全部乱了。跟进去debug了一番,发现是之前解决夏令时的函数只考虑了公历!!!而iOS系统默认有三种日历。公历、和历、佛历。又一次无情的证明了我是一个天朝土包子。


iOS笔记(34) 格志周年系列之夏令时(二)

本文仅作为个人学习记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS方式订阅本站,这样您将能在第一时间获取本站信息.

开篇扯淡

恩,两月没更新blog,hexo都出来新主题来着。其实昨天为了找个背景图找了一小时我会随便乱说。就是为了找一个配合网站标题的背景图。其实hexo默认的就蛮好了,但是为了显示那么一点点与众不同还是替换了一下。

扯淡结束,接上一篇格志周年系列之夏令时(一)

第一阶段Bug

上次说过一个中国高富帅用户发Email来说,他去泰国旅游的时候,日记都不见了。

其实不是日记不见了,日记都好好的躺在sqlite文件里面。而是查询不出来了。日记的保存是用了一个函数去获得了每天的00:00:00. 然后作为唯一标识来区别和查询。

那日期出了啥问题?

我们来快速的分析一下

调用的是

1
2
3
4
5
6
7
8
- (NSDate *) dateAtStartOfDay
{
NSDateComponents *components = [CURRENT_CALENDAR components:DATE_COMPONENTS fromDate:self];
components.hour = 0;
components.minute = 0;
components.second = 0;
return [CURRENT_CALENDAR dateFromComponents:components];
}

里面有两个宏

1
2
#define DATE_COMPONENTS (NSYearCalendarUnit| NSMonthCalendarUnit | NSDayCalendarUnit | NSWeekCalendarUnit |  NSHourCalendarUnit | NSMinuteCalendarUnit | NSSecondCalendarUnit | NSWeekdayCalendarUnit | NSWeekdayOrdinalCalendarUnit)
#define CURRENT_CALENDAR [NSCalendar currentCalendar]

假设你使用过Cocoa时间这些类的话能很容易的看出。dateAtStartOfDay函数就是把你持有的date以当前日历为基础,其他不改,小时,分钟,秒钟设置都为0。这样就能得到一个基于当前日历下的date这一天的00:00:00。

简单看上去没有什么问题,回到高富帅的问题。他出国玩一圈咋时间就变了呢?答案是[NSCalendar currentCalendar]改变了。NSCalendar的改变使得dateAtStartOfDay返回的时间也变了。debug到这一步才发觉靠当初为什么没有想到有时区的这个问题。

自己给自己找一个理由就是到目前为止,我只用过大天朝的+8时间。潜意识里面根本没有说换一个时区这样的概念。(后来某一天我翻了本C语言的书第一章就说了国际化时间的问题,再后来weibo上大家都纷纷表示时间是编程里面一个基础点而且做好不容易,只能说我还是太菜太年轻了。这些是后话了)

说道这里那就开始科普一下地球上时间的问题


iOS笔记(33) 格志周年系列之夏令时(一)

本文仅作为个人学习记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS方式订阅本站,这样您将能在第一时间获取本站信息.

开篇扯淡

两月没写blog,没羞没皮了。以后作息规律一些,blog更新还是频繁一些。格志在2014年2月11日就整整上线一周年了。2013一年做格志,由于自己的技术实在比较菜。导致从上线的第一天起,整个团队跟着一直打补丁。小的坑就不说了,大的坑有两,一个iCloud + Core Data世界性难题。一个是全球时间问题。这篇blog就用来专门记下时间的坑。中间还有个插曲——格志在三月上线了2.0的全新专门为iOS 7设计的版本。时间问题在去年10月份改完以为对了就没有改过。结果3月9号是3月的第二个周日,美国地区进入夏令时。格志中又再次发生了时间问题,导致日记显示不全。之前开会说过放错不可怕,可怕的是放同样的错误。再次放错以后我都呆住了。那可是我写过测试用例的啊。结果当时一run测试就挂掉了。瞬间脑子蒙掉。然后上周通宵了一天,基本每天到3点把世界时间问题给彻底搞定。(希望是彻底)所以趁着我现在还有印象,记录一下。


iOS笔记(32) UbiquityStoreManager 学习笔记1

本文仅作为个人学习记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS方式订阅本站,这样您将能在第一时间获取本站信息.

开篇扯淡

现在都是进入互联网时代,一个互联网的App数据肯定是存在互联网上的。到处都是云,到处都是服务器。如果数据是存储在云端or服务器端。每次数据的读取和修改直接作用于服务器。这样不管你用多少设备,多少平台。数据都能保证是唯一的。但是还有些App需要一些更好的性能和效果的时候往往等不起网络的数据传来传去。这时候需要一些折中的办法来解决这些问题。iCloud就是Apple给出的解决方案。就普通用户来看,iCloud应该是在Apple系中的最优选择。但是从开发者的角度来看iCloud就是个无穷无尽的深渊。

全球有很多开发者致力开发第三方库以便让iCloud能被使用。

UbiquityStoreManager就是其中之一。


iOS笔记(31) CocoaPods 手把手五分钟教你制作自己的podspec文件

本文仅作为个人记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS方式订阅本站,这样您将能在第一时间获取本站信息。

##开篇扯淡
圣诞渐进,各种App都在黑五一波冰点。可以遇见的是12月25号前也会有一大波来临。但是!!!今年买软件貌似已经花了很多钱了。而且,也没有几个想入的了。所以就忍忍吧。

然后,做个宣传啊。我们国际化大厂Sumi的App Grid Diary在紧锣密鼓的开发2.0. 完全iOS7设计。各种给力。到时候希望能给大家带来一个好的App吧。


iOS学习笔记(30) Core Data是如何保存的?

本文仅作为个人记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS方式订阅本站,这样您将能在第一时间获取本站信息。

开场扯淡

恩 一个月没有写一篇blog了。恩。就这样把。


iOS学习笔记(29) 爱不释手的ReactiveCocoa之UIButton

开场扯淡

ReactiveCocoa的迭代速度相当快,一群富有才华和激情的人们在不断的进化ReactiveCocoa。欣欣向荣的景象啊。我这种hello world级别的也就只能使用他们的劳动成果了。上篇blog的时候我还在用1.9.x的版本 现在我已经全面转向2.x了。值得注意的是霓虹友人提交的cocoapods上ReactiveCocoa 2.1 版本我无法编译通过。目前我使用的还是2.0的版本。

介于一个月没有更新blog的速度,这次来写少一点的内容。


Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×