I had a UIButton inside a UITableViewCell and these were being rendered with a black background once I had upgraded the project to iPhone OS 3.0. These table cells were being loaded from their own NIB file.

To stop the black background I needed to set the background of the TableViewCell to white (like you do on most cells after the upgrade), but for the button I also needed to set the UIButton to have the “Clear Context Before Drawing” setting checked.

The background should still be transparent to allow the corners of grouped tables to be shown.

At present I am working on Version 2.0 of Duplicate Image Detector. At present it is nearly as quick as V1.0 for detecting duplicates, and it is now a matter of getting the user interface hooked up.

Version 2.0 will have the following goals:

• Simplified User Interface
• Easier access to advanced features
• Same speed as version 1.0

At present the user interface is coming along nicely and I beleive that it will be easier to use. In initial testing version 2.0 is nearly as quick as version 1.0 but still needs a bit of tweaking.

Once version 2.0 is out the door the next focus will be on improving the performance of the application.

Dius Computing (the reason I haven’t posted much recently) have just launched their new website. It looks pretty good and people won’t be ashamed to link to it now

After a bit of testing I found that there are a couple of issues. The first if you edit a field name and then you click the add button the results aren’t saved. This is easily fixed by deselecting the table first:

- (IBAction)addExtraField:(id)sender
{

[extraFieldsDefinitionTable deselectAll:self];
[NSEntityDescription insertNewObjectForEntityForName:@"ExtraFieldName"
inManagedObjectContext:[self managedObjectContext]];
[self performSelector:@selector(selectLastRowOfTable) withObject:nil afterDelay:0];

}

The second issue was when you add multiple items, their was a chance that the item wouldn’t be editable. An extra line is needed to select the row before you can edit the table.

- (void)selectLastRowOfTable
{

[extraFieldsDefinitionTable selectRow:([extraFieldsDefinitionTable numberOfRows] -1) byExtendingSelection:NO];
[extraFieldsDefinitionTable editColumn:0 row:([extraFieldsDefinitionTable numberOfRows] -1)
withEvent:nil select:YES];

}

Adding those two lines to the code makes it all good.

One thing that feels wrong with a bindings app is that when you add a new record to a table you then have to select that record with the mouse before you can edit that record. In my mind this feels just wrong and very ‘unMacintosh’. If you add a new playlist to iTunes the new playlist will be selected and ready to be renamed.

It is pretty easy to fix. In this case I am using Core Data and Bindings. You need to add one action to your controlling object and you also needs an outlet to the table in which the data has been added. In this case the object extraFieldsDefinitionTable is the NSTableView which is bound to the ExtraFieldName table in my data model.

- (IBAction)addExtraField:(id)sender
{
[NSEntityDescription insertNewObjectForEntityForName:@"ExtraFieldName"
inManagedObjectContext:[self managedObjectContext]];
[self performSelector:@selector(selectLastRowOfTable) withObject:nil afterDelay:0];

}


- (void)selectLastRowOfTable
{
[extraFieldsDefinitionTable editColumn:0 row:([extraFieldsDefinitionTable numberOfRows] -1)
withEvent:nil select:YES];
}

The reason this final part of code is called via a performSelector function is it allows the run loop to complete and update the tables data source from the core data model. If you are writing your own data source functions you can call reloadData on the table within the addExtraField function and then the editColumn without using performSelector.

The new version of Body Diary presents a list of additional fields to the user to fill in. The number of fields is determined by the user. This data hasn’t been assigned to coredata so I decided that the easiest way to show this would be to create a mutable array and have that as the data source for Cocoa Bindings. Whenever a record is added to the system the array is recreated.

My first attempt at working with the data I went straight to the array and editted the data. This left the display out of sync with the data. A quick scan of the documentation pointed out that I should be instead using the NSArrayController to manipulate the data. I modified my code but I was soon stuck with nothing working. I tried everything, recreating controller objects, modifying my code, stepping through line by line. Nothing worked and I was getting very close to just rewriting everything as traditional table delegate methods.

I decided to remove all my debugging trials and strip everything back to the bare essentials. Once I did this I noticed that the class controlling the window was crashing when I quit. It turns out that my code to set the MutableArray that the NSArrayController was using was back to front. So instead of retaining the newArray, releasing the old, and then assigning the new to the old, I was retaining and releasing correctly but was assigning the old to the new.

A quick switch of the code and my NSArrayController was behaving perfectly. So the old “Problem Exists Between Keyboard and Chair” strikes again.

I have started working with core data for a couple of days now and I have a few first impressions:

The initial core data videos and tutorials take the easy path and show you the add a row to the table/delete a row from the table type example. The first version of Body Diary worked this way and I had a number of complaints about the user interface. It takes a little more effort to get this working correctly.

The bindings dialogs aren’t really intuitive. As I get used to the interface I am sure that I will understand it better once I have used it for a while.

I like the core data entity and relationship mapping. To me it feels like building a ER diagram for a database without having to worry about primary keys and foriegn key mappings. I would like to be able to drag and drop the relationships but that is probably a symptom of me spending to much time using Visio to document peoples databases.

In all I can see how core data will help me be more productive. Hopefully I will be able to climb up the initial learning curve in the next couple of days (I only get a couple of hours a day to work on Body Diary) and then bask in the speed that is developing applications using core data.

I have decided to rewrite Body Diary using Core Data, after seeing Apple’s video tutorials on Core Data. Previously Body Diary hasn’t used either Core Data or Bindings, so this version will be a complete rewrite. The reason for using core data are:

• Faster coding
• No coding of sorting/filtering routines
• Should create an app with better stability
• I probably should learn these brand new technologies

Body diary is a pretty simple application so it should be an easy introduction for me to Core Data. The only real challenges I see with Body Diary are:

• Need custom code to handle the charting module
• Need code to import existing Body Diary files.

Also body diary will have a couple of new options. The main request people have is that they want to include an extra field or two. The main problem is that different people want to include different fields. Therefore I hope to incorporate the option to add any number of additional fields to the body diary application, and to chart those fields. The other main request is
for the charting module to show a floating average on the chart. I will also include the option to filter the results so you can view the graph for a set time frame.

Before diving in I thought I would read up a bit on Core Data. I have found the following useful:

• Core Data Tutorial
• Apple Recipe handling samples
• Low level App using core data
• Apple’s core data reference
• Core Data Programming Guide: (Good overview of common questions about core data)