Learn Objective-C on the Mac - Mark Dalrymple [91]
Now save your work, Build & Run in Xcode, and behold! Assuming that everything’s configured correctly, you should now be able to add gigs to each band’s info.
Wrapping Up Relationships
In this chapter, you’ve expanded the old data model, growing it from a single entity on its own to a full complement of entities, interrelated with relationships. You’ve also seen how each of those relationships can be expressed in a GUI (for example, using a popup list to choose the remote end of a to-one relationship, and a table view to show all the contents of a to-many relationship), configured, and managed entirely with Cocoa Bindings. Not to beat a dead horse about this “visual programming” business, but it bears repeating that everything in this chapter was done without a single line of code on our part.
NOTE: Our use of the term “visual programming” has nothing to do with Microsoft’s use of the word “visual” in its development tools. The idea behind visual programming is to allow a program, or some portion of it, to be constructed using graphical components that don’t require the sort of textual, procedural programming that’s traditionally been used for writing software. Cocoa embraces visual programming to some extent, letting you put together application prototypes or even entire applications using just the Xcode data modeler and Interface Builder. However, it’s not intended to comprise a complete visual programming system, so for every Cocoa app you build, you will out of necessity have to break down and write some code!
Furthermore, these usage patterns can be applied equally well to your own applications. Just the act of modeling your problem domain, defining entities and relationships, can often start giving you a sense of how to build your GUI. As you get farther along in the application development process, you’re sure to find more ways to connect different kinds of controls to your data using Cocoa Bindings, and will sometimes find a need to supplement that by writing code to connect things and shuffle data between objects.
As you work through the rest of this book, you’ll see several more examples of applications that use Core Data and Cocoa Bindings as core parts of their architectures, so you’ll see even more approaches to using these technologies. The next chapter, Searching and Retrieving Core Data, is the last chapter dealing exclusively with Core Data, showing you how to limit the extent of what you’re showing in your GUI, an absolute necessity for any application work with a large set of data.
Chapter 9
Search and Retrieve Core Data with Criteria
In the MythBase examples in Chapters 7 and 8, you learned the basics of how Core Data works, letting you create, retrieve, update, and delete objects from a backing store with a minimum of fuss. So far, we’ve been working primarily with full data sets in MythBase. For most of the entities we’ve used (MythicalPerson, MythicalBand, and MythicalVenue), all the objects for each entity are loaded during application startup, and kept in memory for the entire life of the application. That’s okay for an application like MythBase, which maintains a small database, but what if one of your main entities consists of thousands or millions of instances in a backing store? Your app would load everything from storage when the app launches, which would probably lead to the app filling up all available memory, swapping to disk, and so on. Apart from that problem, you’d also probably end up with