Welcome!

.NET Authors: Alin Irimie, Colin Walker, Maureen O'Gara, Reuven Cohen, Data Recovery Software & Tools

Related Topics: .NET

.NET: Article

Core Data - Almost Too Easy?

I have a rather unique perspective on persistence tools because I tested and developed in every conceivable environment

Kevin Hoffman's Blog

I am working on another sample application that I am using as a means of teaching me some more things about Cocoa and programming on the Mac in general. I have been particularly fascinated with Core Data, so I started using it again in a new application.

I have a rather unique perspective on persistence tools because I have probably tested and developed in just about every conceivable environment for rapidly creating data-bound desktop applications, including some that called themselves "4GL" and were basically code generators that would inhale a data model and exhale an application. The general feeling I have come away with from tools that make it so that you can write a data-bound desktop application "with no code at all for the low-low price of $19.95!!" is that such tools are crap. They spend so much time insulating you from what is really going on that as soon as you want to do something other than build the "hello world" samples - you're knee deep in crap without a shovel.

This is not the case with Core Data. At first, I was extremely skeptical. I thought to myself, self: this is to easy. This is going to get ugly when I need to make some minor tweaks. So, I went ahead and wrote another sample app and sure enough, I needed to perform a minor tweak.

Problem 1: I created my model. I have two attributes, one is a number (Int32) and the other column is a date column. I created a table view and bound the columns to the attributes in my entity. Everything looked fine. I ran the app. Whenever I tabbed out of a field, I'd get an error showing up in my Console complaining about a data type mismatch. Basically it looked like the table view was sending a string to the bound attribute, and the bound attribute needed an integer or a date.

Solution 1: Thanks to some tips from a knowledgeable resource on Cocoa, I figured out that I could just drag a number formatter into the number cell, and drag a date formatter into the date cell. Problem solved. My thoughts: holy crap that's easy.

Problem 2: I wanted to make it so that whenever I clicked the "+" button that was linked to the "insert:" action, the date on the underlying model object (which is a core data entity) would be today's date. There didn't seem to be any way to do this in the user interface, so I got scared.

Solution 2: It was actually really , really easy. I created a new class that inherited from NSManagedObject called KHWeighInEntity. I then changed the type of my entity from NSManagedObject to KHWeighInEntity. Then, I overrode a single method in this class as follows:

- (void)awakeFromInsert
{
    [self setValue:[NSCalendarDate date]
forKey:@"weighInDate"];
}

That's it. Done. I didn't have to go through the hoops of building a brand new "wheel", all I had to do was override the part of the wheel that needed tweaking, and I was done. To me, scenarios like this are why inheritance was conceived. Here's the fantastically cool part: I can continue to model and extend my entity in the entity designer, and it won't impact the code I've already written. I don't have to manually add attributes to my new custom class... it's still all extremely seamless.

The more I use Core Data (and, of course, Cocoa), the more I become a huge fan. In short, Core Data is a rare example of a solution that allows you to rapidly build solutions without writing a single line of code...and... when you need to write code to create a more powerful solution, that task is simple, quick, and painless.

tags:          
links: digg this  del.icio.us  technorati reddit

More Stories By Kevin Hoffman

Kevin Hoffman, editor-in-chief of SYS-CON's iPhone Developer's Journal, has been programming since he was 10 and has written everything from DOS shareware to n-tier, enterprise web applications in VB, C++, Delphi, and C. Hoffman is coauthor of Professional .NET Framework (Wrox Press) and co-author with Robert Foster of Microsoft SharePoint 2007 Development Unleashed. He authors The .NET Addict's Blog at .NET Developer's Journal.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
mmalc 06/30/09 06:52:00 PM EDT

I appreciate this is an old post, but since it was highly-ranked in a Google search:
Re:

[self setValue:[NSCalendarDate date] ...

You shouldn't use NSCalendarDate objects to represent dates with Core Data. You should just use a standard NSDate object.

In general (particularly with Mac OS X v10.5 and later, where they're synthesised for you), you're also encouraged to use custom accessor methods rather than key-value coding. They're much more efficient and much less error-prone.

.NET News 04/18/07 03:19:15 PM EDT

I have a rather unique perspective on persistence tools because I have probably tested and developed in just about every conceivable environment for rapidly creating data-bound desktop applications, including some that called themselves '4GL' and were basically code generators that would inhale a data model and exhale an application.