如何使用KVO更新属性
我想创建一个应用程序来记录我慢跑的时间并使用 Core Data 来存储信息。我想存储每次锻炼的日期、距离和跑步时间。我还希望能够显示一个摘要，其中包含我跑步的总次数和跑步的总距离。
在我的设计中，我可以直接从 Workout 对象显示摘要。我跑步的次数只是锻炼对象的数量，我可以将每次锻炼的距离相加以获得跑步的总距离。然而，我认为第二次操作成本太高，因为每次我想显示该数据时，我都必须扫描整个数据库（这与 iTunes 中的问题相同，您想要显示您的音乐总小时数）设备）。我可以在每次应用程序启动时将此信息存储在属性中，但我想这会导致启动缓慢。因此，我想我宁愿有 2 个 coredata 对象总结和锻炼：
+---------------------+ +---------------------+
|Summary | |Workout |
+---------------------+ +---------------------+
|totalDistance | <--------------->> |date |
|totalAmountOfWorkouts| |distance |
+---------------------+ |time |
+---------------------+
现在问题来了。摘要应该如何更新？
我可以手动更新totalDistance和totalAmountOfWorkouts。我想象实现某种 updateWorkout 方法，每次创建新的锻炼时都会触发该方法。但是，我知道 Coredata 已经具有观察功能，并且可以告诉我何时插入新的 Workout 对象，并且我可以更新摘要：KVO。我从未使用过 KVO，我想知道这是否是使用 KVO 的正确情况？但你如何做到这一点呢？实际上 KVO 是解决这个问题的最佳方法还是我应该在 Workout 中实现一个协议并将 Summary 分配为委托？我迷迷糊糊地记得听说过 KVO 模式很难调试。
总结起来，我的问题是：
Q1：我应该让totalDistance直接扫描数据库吗？
Q2：我应该使用 KVO 还是委托模式？
Q3：totalDistance如何更新？
I want to create an application that logs when I have gone jogging and uses Core Data to store the information. I want to store each workout with the date, distance and time I have run. I also want to be able to display a Summary which contains the total amount of times I have gone to run and the total distance run.
In my disign, I could display the summary directly from the Workout objects. How many times I have run is just the amount of workout objects and I could sum up the distance in each Workout to obtain the total distance run. However, I think that the second operation is too costly because I have to scann the whole database every time I want to display that data (This is the same problem as in iTunes you want to display the total amount hours of music you have in your device). I could store this information in a property every time the app lunches, but I guess that would cause a slow start up. Because of that, I thought I rather have 2 coredata objects Summary and Workout:
+---------------------+ +---------------------+
|Summary | |Workout |
+---------------------+ +---------------------+
|totalDistance | <--------------->> |date |
|totalAmountOfWorkouts| |distance |
+---------------------+ |time |
+---------------------+
Now here it comes the question. How should Summary be updated?
I could manually update the totalDistance and totalAmountOfWorkouts. I imagine implementing some sort of updateWorkout method which is triggered every time I create a new Workout. However, I know that Coredata has already observation capabilities and could tell me when a new Workout object has been inserted and I could update Summary: KVO. I have never used KVO and I wonder if this is the right case to use KVO? But how do you do that? Is actually KVO the best approach to solve this problem or should I rather implement a protocol in Workout and assign Summary as a delegate? I vagally remember to have heard that the KVO pattern is difficult to debug.
Summarizing, my questions are:
Q1: Should I get totalDistance directly scanning the DB?
Q2: Should I use KVO or the delegate pattern?
Q3: How is totalDistance updated?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用最简单的 API。假设您有一组获取的锻炼。然后只需执行
“仅当这不能满足您的性能要求”时，请考虑使用 KVO 或其他机制来缓存距离值。如果性能可以接受，实时计算总是优于缓存。但我发现很难相信 CoreData 无法处理您一生中实际可以进行的锻炼量。
Use the simplest API available. Let's say you have an array of fetched Workouts. Then simply do
Only if this doesn't meet your performance requirements, consider KVO or other mechanisms for caching the distance value. Real-time computation is always preferable to caching if the performance is acceptable. But I find it hard to believe that CoreData couldn't handle the amount of Workouts you could realistically do in a lifetime.
如果您有很多 Workout 对象，并且要在具有 batchSize 的表视图中显示它们，那么您可以创建一个 NSFetchRequest 在 SQL 级别上执行该计算，而不是迭代所有对象，这应该会显着提高性能和内存。
以下博客文章中的示例
http://iphonedevelopment.blogspot.co.il/2010/11/nsexpression.html
If you have alot of Workout objects and you're displaying them in a tableview with batchSize, instead of iterating over them all you can create a NSFetchRequest that performs that calculation on the SQL level which should be significantly better performance and memory wise.
an example at the following blog post
http://iphonedevelopment.blogspot.co.il/2010/11/nsexpression.html