7: Core Data Basics in Java

Drawing DataMatrix in Java 7: Core Data Basics

} return YES; }

Be sure to enter that method somewhere above the validateForInsert: and validateForUpdate: methods, so the compiler knows how to deal with it properly. This method is a little more complicated than the single attribute validation method. We do the same sort of checking for a problem, returning YES if it s okay, and otherwise constructing an NSError, setting the error parameter to point at it, and returning NO. However, in order to play nice with Core Data, we have to check for the existence of a pre-existing error, and if there is one, combine it with our own into a special kind of error. This lets Core Data eventually report back all the errors it finds when it tries to save. This error combining is done using another method of our own, errorFromOriginalError:error:, which we should add to our class:

- (NSError *)errorFromOriginalError:(NSError *)originalError error:(NSError *)secondError { NSMutableDictionary *userInfo = [NSMutableDictionary dictionary]; NSMutableArray *errors = [NSMutableArray arrayWithObject:secondError]; if ([originalError code] == NSValidationMultipleErrorsError) { [userInfo addEntriesFromDictionary:[originalError userInfo]]; [errors addObjectsFromArray:[userInfo objectForKey:NSDetailedErrorsKey]]; } else { [errors addObject:originalError]; } [userInfo setObject:errors forKey:NSDetailedErrorsKey]; return [NSError errorWithDomain:NSCocoaErrorDomain code:NSValidationMultipleErrorsError userInfo:userInfo]; }

Basically, this method checks the originalError parameter to see if it already contains multiple errors, and if so, just adds the new one to the list. Otherwise, it combines the two single errors into a new multiple error object. With all that in place, you should now be able to compile and run, select a MythicalPerson, set their power above 50, their divinity below 100, and try to save. You ll see an error telling you about the problem. You can also make sure that reporting of multiple problems works, by leaving this power/divinity inconsistency in place, changing the name to Bob, and trying to save. You should see a warning panel telling you that multiple validation errors occurred, but you don t see details about any of them. This suggests a good idea for a future expansion of the app delegate s saveAction: and applicationShouldTerminate: methods: come up with a way to display multiple errors instead of just calling presentError: as is currently done. There s something to tackle on a rainy day!

Another common sort of simple business logic calls for the creation of custom attributes that are based on the values contained in an object s attributes. For example, if you have an entity with firstName and lastName attributes, you might want to make a custom attribute called fullName that combines the two together. This sort of thing is a piece of cake with Core Data. In our case, let s say we want to add an attribute to MythicalPerson called awesomeness, which will be calculated from the MythicalPerson s power, divinity, and goodness. We start off by defining a method called awesomeness in MythicalPerson s implementation:

- (int)awesomeness { int awesomeness = [[self valueForKey:@"divinity"] intValue] * 10 + [[self valueForKey:@"power"] intValue] * 5 + [[self valueForKey:@"goodness"] intValue]; return awesomeness; }

With that in place, you can call the awesomeness method on any MythicalPerson and get the result. This also works with Cocoa Bindings of course, so we can easily bind a GUI control s value to this new property. Go back to Interface Builder, make the window and box a little bigger, and add a label and a level indicator from the Library window, something like you see in Figure 7 11.

Figure 7 11. MythBase, now with added Awesomeness!

Now select the Awesomeness control, and bring up the Attributes Inspector. Set the Style to Continuous, and the Minimum and Maximum to 0 and 1600, respectively. Now switch to the Bindings Inspector, and bind the level indicator s Value via the Mythical Person Array Controller, with the controller key selection and the model key awesomeness. Note that Interface Builder doesn t know anything about awesomeness, so you ll have to type it in yourself instead of just picking it from the combo box; we re sure you ll agree that s a small price to pay for awesomeness. Save your changes, switch back to Xcode, Build & Run, and off you go. Switch between different rows in the table view, and you ll see the bar of awesomeness change. Drag a slider and, now wait a minute; the awesomeness value doesn t change! The reason for this is that no part of Core Data, not our model file, not our MythicalPerson class, not the controller we re using, knows that awesomeness depends on other values, and needs to be recalculated if they change. This is fixed by implementing one more small method in MythicalPerson:

+ (NSSet *)keyPathsForValuesAffectingAwesomeness { return [NSSet setWithObjects:@"divinity", @"power", @"goodness", nil]; }

This is another method name that s constructed dynamically based on an accessor name. We saw this pattern when validating a single attribute as well. In this method, we return a set of attribute names that our awesomeness attribute is dependent on. With this in place, Core Data will automatically call this method at some point, and sort things out so that changes made to any attributes in the set will also trigger controllers to update any objects with bindings to the awesomeness attribute. Build and run your app, and now the green bar changes when you drag one of the other sliders. Awesome!