最近在做日历同步的需求，趁着已经提测，整理一些坑坑洼洼的地方。
和产品经理一起研究了一下市面上该功能的实现，绝大多数都是把本地手机日历的日程单向同步到自己app中去。而我们产品经理反其道而行，同步依然是单向的，但是是要从app的日程业务中把数据同步到日历中去。其实这样的需求对于我们本身的业务来讲是说得通的，而且不需要通过push消息就能让用户自己去定义提醒的时间。但是在预研阶段就发现了问题，所以正式开发以前，给她们总结了一些解决思路和不可避免的问题。
问题一：EKEvent对象的eventIdentifier属性是只读的
@property(null_unspecified, nonatomic, readonly) NSString *eventIdentifier;
看到readonly我瞬间明白了其他APP为什么是手机本地日历单向同步到应用中，因为业务对象的唯一标识不能和本地的日历建立有效的连接。这样就会导致如果我们对APP内日程的数据进行的更改或者删除操作，本地日历中的日程就没有办法同步更新，因为匹配不上~
解决方案：将我们的日程id带入到本地日程中去。
eventIdentifier用不了了，只能找其他属性，并且是string类型，最后决定用url，当然做了一些其他处理。不过问题依然是有的，比如该属性是暴露给用户的，用户可以自己去编辑。那么就会导致有新的编辑过的数据过来以后，我只能把该日程处理成新增日程。
问题二：获取本地日历中的日程数据数据量可能会很大，导致与服务端返回的新数据进行匹配的时候双重for循环影响效率（虽然用户感知不到）
解决方案：使用allowsContentModifications属性
-(NSMutableArray*)getLocalSchedules{
NSMutableArray *allowsModifyEvents = [NSMutableArray array];
NSDate *startDate = startdate;
NSDate *endDate = enddate;
NSPredicate *pre = [self.store predicateForEventsWithStartDate:startDate endDate:endDate calendars:nil];
NSArray *events = [self.store eventsMatchingPredicate:pre];
events = [eventssortedArrayUsingSelector:@selector(compareStartDateWithEvent:)];
for(EKEvent*eventinevents) {
if (event.calendar.allowsContentModifications == YES) {
[allowsModifyEventsaddObject:event];
}
}
returnallowsModifyEvents;
}
是的，由于我们手动添加的数据都是可以手动编辑的，所以event的allowsContentModifications这一只读属性刚好可以用到。可以减少很多系统日历自带的event对象，比如节假日、节气等等。
问题三：日程需要分账户
解决方案：使用EKCalendar
//为日程添加日历分类
EKSource*myLocalSource =nil;
EKCalendar*myLocalCalendar;
NSArray *calendars = [self.store calendarsForEntityType:EKEntityTypeEvent];
NSString*calendarTitle = [NSStringstringWithFormat:@"%@",userName];//这里使用username是因为我们的APP可以进行用户切换，产品经理希望不同用户的日程保存到不同的分类下。但是由于EKCalendar的calendarIdentifier属性也是只读的，所以目前只能用username进行本地和服务端返回数据的匹配。
//日历优先取本地已有的
for(EKCalendar*calendar in calendars) {
if([calendar.title isEqualToString: calendarTitle]) {
myLocalCalendar = calendar;
break;
}
}
//本地没有则新建
if(myLocalCalendar ==nil) {
//先取已经存在本地的个人source
for(EKSource*calendarSource in self.store.sources) {
if(calendarSource.sourceType==EKSourceTypeLocal) {
myLocalSource = calendarSource;
break;
}
}
//EKSource的类型有很多种，Local类型在用户打开日历的cloud同步以后会变成CalDAV类型
if(myLocalSource ==nil) {
for(EKSource*calendarSource in self.store.sources) {
if(calendarSource.sourceType==EKSourceTypeCalDAV&&
[calendarSource.titleisEqualToString:@"iCloud"]) {//该判断条件不知道有没有更好的方案，也是在网上找到的。
myLocalSource = calendarSource;
break;
}
}
}
myLocalCalendar = [EKCalendar calendarForEntityType:EKEntityTypeEvent eventStore:self.store];
myLocalCalendar.title= calendarTitle;
CGColorSpaceRef rgbSapceRef = CGColorSpaceCreateDeviceRGB();
CGFloatrgbComponents[] = {1,0,0,1};// RGBA 颜色组件
CGColorRefrgbColorRef =CGColorCreate(rgbSapceRef, rgbComponents);
myLocalCalendar.CGColor= rgbColorRef;
myLocalCalendar.source= myLocalSource;
NSError*err;
[self.store saveCalendar:myLocalCalendar commit:YES error:&err];
if (err) {//新建日历失败的话则将日程的日历分类到默认日历下
[newEventsetCalendar:[self.store defaultCalendarForNewEvents]];
}else{
[newEventsetCalendar:myLocalCalendar];
}
}else{
[newEventsetCalendar:myLocalCalendar];
}
结论：EventKit框架中有太多的只读属性的对象，其实正确的做法是把已经存到本地的EKEvent对象的eventIdentifier属性返回给我们自己的服务器，让后台与业务日程进行关联。但是目前该方案由于种种原因没有最终拍死，所以只能原生负责第一期的需求先实现。后面再慢慢埋坑吧~基本上一些重要的代码也就上面一点点，就不上demo了。其实我蛮喜欢做这样的需求的，没有UI\UE。后台或者前端返回来数据我就处理数据就好了。不到一天时间就能搞定，不过前期一定要做好预研工作，把问题尽快的暴露给项目组，然后大家一起讨论解决方案，后面才能水到渠成。
