核心数据按年份分组并按日期排序

Question

我是 Core Data (iOS 7) 的新手，我正在尝试从 FMDB 上的 SQL 切换到 Core Data 获取数据的方式。

我有一个条目实体，其中包含如下数据：

flightDate (date) |  duration (float)
-------------------------------------
  2014-05-21      |      1.0
  2014-08-03      |      2.0
  2013-03-27      |      3.0
  2013-09-16      |      4.0
  2012-12-20      |      5.0
-------------------------------------

我的最终目标是将这些数据呈现在 tableView 中，以年份作为部分标题，并按时间倒序在其下方列出该年份的每个条目。 所以数据看起来像这样：

-- 2014 --
Aug 3, 2014     (2.0)
May 21, 2014    (1.0)

-- 2013 --
Sep 16, 2013    (4.0)
Mar 27, 2013    (3.0)

-- 2012 --
Dec 20, 2012    (5.0)

这在 SQL 中很容易实现，但经过数小时的研究，这正在变得类似于 Core Data 中没有麻醉的心脏手术。

最后，我认为拥有这样的 NSMutableDictionary 会很好：

{
  2014 = {
    <Entry: Aug 3, 2014, 2.0>,
    <Entry: May 21, 2014, 1.0>  
  },
  2013 = {
    <Entry: Sep 16, 2013, 4.0>,
    <Entry: Mar 27, 2013, 3.0>  
  },
  2012 = {
    <Entry: Dec 20, 2012, 5.0>
  }
}

...以正确的顺序并准备传递给我的 tableView 代表。 如何从 Core Data 对象获取时间排序和分组的字典数据而不会失去理智？

提前致谢。

Answer 1

使用NSFetchedResultsController 。
您可以找到根据Apple的日期将表格分成多个部分的工作示例！

Answer 2

1. 创建一个 NSFetchRequest。 为日期列添加排序描述符。 这将使您的行井然有序。
2. 在您的托管对象上下文上执行获取请求，取回您的结果
3. 将每个日期分解成组件（使用类似这样的.
4. 迭代、构建数组，无论您需要做什么来将结果转换为您想要的格式。

1 看起来像这样：

NSFetchRequest *fetchRequest = [NSFetchRequest fetchRequestWithEntityName:@"Entry"];
NSSortDescriptor *sortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@"flightDate" ascending:NO];
fetchRequest.sortDescriptors = @[sortDescriptor];

Answer 3

核心数据存储NSDate s。 它们是不透明的、抽象的、时间戳。 他们天生就没有一年。 根据您的时区和日历，相同的NSDate将显示不同的年份。

例如，如果格式正确，表示 2001 年 1 月 1 日 GMT 00:01 的NSDate将在 GMT 电话上显示为“2001”。 它将在 EST 的电话上显示为“2000”。 如果手机设置为使用中国日历而不是公历，它将再次显示为非常不同的内容。

我不清楚为什么你会认为这个“SQL 中的简单易行”。 可能您正在以某种方式大规模简化问题？

您可能想要添加一个临时属性来返回年份。 这将是NSDate上的NSCalendar驱动计算，涉及获取NSDateComponents 。

您可以提供瞬态特性为sectionNameKeyPath一个NSFetchedResultsController 。

但是请注意语义：除非您检查表中的每一件事，否则您不知道年份是多少。 所以你需要获取每一件事。 出于性能原因，您可能希望明确告诉您的 fetch 请求不要返回错误*，因此您不会从 Core Data 的自动内存管理中获得任何好处。

(*) Core Data 懒惰地获取其图中的对象。 查询通常会返回错误，这些错误是对原始对象的引用，因此可以找到它但找不到实际数据。 但是由于对属性的访问是同步的，如果您像填充一样遍历错误，这意味着糟糕的性能——Core Data 无法预测您接下来要访问哪些对象，因此每次访问都是对持久存储的单独访问。