You may have noticed a bit of a lull between my last few posts to this site; I apologise in advance for the shameless plug but this is because I have been working with Steve Scott (aka Scotty) of the Mac Developer Network and Late Night Cocoa etc podcasts to bring you a Macintosh Developer Conference taking place here in Europe next April 2009.
In this post I’ll walk through writing a custom subclass of NSView that can bind to an NSArrayController to display information either from some generic array connected to the array controller, or from a Core Data object model.
The view we’ll be creating is a custom view to display a pie-chart; in the sample app the pie-chart will be drawn from data entered in an NSTableView. The finished application looks like the following:
Chances are, if you’ve developed any kind of Cocoa application, you’ve probably made use of Cocoa Bindings in one way or another, particularly when it comes to Core Data. The technology is ‘key’ to so many of the underlying frameworks but it is a technology that tends to be often-used but frequently not fully understood.
If you are someone who happily binds Array Controllers and View objects together using Interface Builder but have always wondered discretely exactly how the magic behind the scenes happens, or if you just don’t quite comprehend the difference between ‘KVC’ and ‘KVO’ (or perhaps can never quite remember what they stand for…), this article might help you out. In it, I’ll attempt to demonstrate a ‘faux-bindings’ methodology that connects a value from one object with a value from another object, but without using the actual Apple Cocoa Bindings technology. The bare-bones of how the ‘faux binding’ works will be there for all to see; while the internal workings of Cocoa Bindings are a little different, this will hopefully at least show you what, how and why certain things are required for the real Cocoa Bindings to work successfully.
By default, a Core Data application will refuse to load data created using an older data model. So, if you’ve been using one version of your model for ages and have loads of data, it’s a bit of a pain that should you wish to add an entity, attribute or relationship or make other changes to your model, you won’t be able to open the old data in a new version of your application.
Prior to OS X 10.5 if you wanted to convert data from one model version to another, you had to handle the conversion code entirely yourself. With Leopard, however, Apple built in versioning and migration capabilities to make dealing with data migration a great deal easier.
This article looks at how you can support data migration in your Core Data applications. It shows how to handle changes entirely using Data Model versions and Mapping Models, before looking at customizing the process by using custom migration classes.
Apple’s Sync Services framework allows applications and devices to keep in sync with each other’s data. If you subscribe to the MobileMe service, for example, it is Sync Services that handles synchronization between the server, your computers and any connected devices such as an iPhone. This article discusses adding synchronization capabilities to Core Data applications. We’ll start by looking at the information you must provide to allow synchronization to take place and then build two sample applications that will keep in sync with each other.
It is now possible to download example finished projects for each of the walk-thru articles so far:
One thing I frequently need to support in my applications is the display of data in a table view with a specific order (not necessarily alphabetical/numerical order) along with the ability to rearrange that order by dragging and dropping items in the table.
In this article I’ll look at how I accomplish this task using these steps:
- Setup order in Core Data by maintaining a ‘viewPosition’ for each object.
- Write code to support rearrangement of the order (ie moving an object(s) above/below another object in the user interface).
- Setup Drag and Drop on the
NSTableViewto call the rearrangement code.
In this post we’ll walk through one way to use a custom cell to display multiple managed object values in a single table view cell using bindings. The obvious question here is how to bind the Value of the table column in Interface Builder to more than one Model Key Path from Core Data. You can’t, for example, type in a string of attributes like ‘firstName, lastName’ or anything like that to specify that multiple values be taken.
Previously we’ve covered multiple windows and managed object contexts in Core Data applications. In this fairly brief article we’ll cover how to open a display/editing window for an object when that object is double-clicked in a table view.
In the last article, I walked through a simple multi-window Core Data document application. The pretext of this article is to show how I use multiple Managed Object Contexts in my Cocoa Core Data apps. We’ll be building on the application created in the last article by adding in two new windows; an ‘Add New Department’ window and an ‘Add New Employee’ window.
The application we created previously lets you insert new departments and people by clicking on the ‘+’ buttons before editing the values in the relevant table view. When you click the ‘+’ button, the new managed object that is created has blank string attributes that show up in the table view as an apparently invisible line. One way to change this behaviour would be to subclass
NSManagedObject for our Department and Person entities and give a newly created object some default values. In this article, however, we’ll change the ‘Add’ behaviour to open yet another new window in which you can type the initial values before the new object is inserted into the list.