I found a bug today with Xcode’s refactoring tool (radar://5723465) that could be a headache if you don’t watch for it. If you refactor the name of a method, calls to used through an @selector, like [self performSelectorOnMainThread:@selector(someMethod:) withObject:obj waitUntilDone:NO], will not be changed. You have to pick those up yourself. This could be a headache since it won’t be caught until runtime.
Developers, keep an eye out for Changes. I saw a demo of it last night and I think most of you are going to want it. It’s really cool.
The Mysteries of iCal, Revealed! (Via Jens Ayton.):
One of the minor yet shiny new features of Mac OS X 10.5 is that iCal’s dock icon now shows the correct date even when iCal is not running. Some assumed this to be hard-coded functionality in the dock, but a few brave souls – well, one, being me – decided to find out.
Very interesting. Jens shows how cause the dock to update it’s without the app running like iCal does in 10.5. The functionality probably isn’t completely safe to count on since it uses a private class, but it could be a cool add-on to some apps. I haven’t thought of a good use for it yet in either of my apps. Maybe we’ll come up with something cool.
The November Phoenix Cocoaheads meeting is tomorrow night at 7. This months topic is Cocoa Bindings and I’m going to be giving the presentation. So if you want to see me stumble through a talk, stop on by. =)
Location:
Target Training International
16020 N 77th St
Scottsdale AZ 85260
United States
Drew McCormack has up what looks to be a great tutorial on the new NSOperation and NSOperationQueue classes for threading in Cocoa. The classes promise to simplify threading and make it easier to implement well behaved, multi-threaded apps.
F-Script is an open-source scripting layer dedicated to Cocoa. If you aren’t using it yet, this is your chance to learn how it can improve your productivity as well as those of the users of your own Cocoa applications. In this article, our goal will be to produce a nice little animation using fancy Core Image effects. In doing so, we will learn the basics of F-Script.
Posting mainly for myself to come back and read. Philippe has up what looks to be a good getting started tutorial on F-Script that walks you through using it with a few Core Image items in an app. F-Script is one of those things that I’ve seen around and played with a little, but never really sunk my teeth into it. I need to play with it a bit more since it’s supposed to be a good Cocoa development aid.
A Phoenix Cocoaheads chapter has finally started up! The first topic will be “Beginning Cocoa
Development” and will involve setting up and running Xcode through
learning how to develop in Cocoa. Bring any projects you’ve been
working on and would like to show off!
Date: October 11th, 2007
Time: 7-9pm (we’ll hit a local watering hole after the meeting for a
bite and/or a round of beers if folks are interested)
Location:
Target Training International
16020 N 77th St
Scottsdale AZ 85260
United States
If you’re interested in attending, please send an email to
Greg so that they know how many people to expect
I’ve been having some more fun with NSPredicates. They have a really annoying “feature” in 10.4 that gave me a bit of a headache and will hopefull be changed before long. According to the Predicate Programming Guide:
In Mac OS X v10.4, wildcard characters do not match newline characters.
I took that to mean that the wildcard portion of the match could not could not contain a newline. Something like “a\n b” would not match for “a*b”. What it really means is that if the string has a newline character in it, a match will not occur. So if the string is something like “this is an example\n string”, a LIKE predicate matching on “*exa*” will not match. Any newline characters need to be stripped out first.
It looks like I ran into a major difference tonight between fetch requests and filtering an array on how predicates are evaluated. I’ve been using predicates that look like [NSPredicate predicateWithFormat:@”department == %@”, [someDepartment objectID]] in CoreData fetch requests with no problems. If I used that predicate on against the employee entity, I’d get back an array with all employees that are in someDepartment.
So tonight when I had to filter an array of employee objects I figured I’d use a predicate with the same format and I’d be all set. Boy was I wrong. Unfortunately it appears that relationships are not matched on NSManagedObjectIDs when filtering an array with filteredArrayUsingPredicate:. I get back an empty array. If I change the predicate to [NSPredicate predicateWithFormat:@”department == %@”, someDepartment], I get back the correct objects. The objectIDs are not being checked against target’s ID. As far as I can tell, there’s no documentation on this behavior. So now I get to create a work around for this behavior. If your wondering why I’m using the IDs instead of the actual objects and need to find a workaround, it is because there is some archiving involved and multiple contexts within a single persistence stack.
I’m working on an app that loads a WebView with data using a custom NSURLProtocol and uses CoreData. Tonight I switched the CoreData store from XML, which I use while I’m still playing around with the model, to an SQLite store. Everything looks good until I start changing the selection that feed the WebView its data. I started randomly crashing with the debugger breaking at different points with the following printed:
Iris[2336] An uncaught exception was raised Iris[2336] library routine called out of sequence Iris[2336] *** Uncaught exception: <NSInternalInconsistencyException> library routine called out of sequence
The only thing that the crashes seemed to have in common was that a faulted relationship was trying to be loaded. A quick search of cocoabuilder.com didn’t yield any solutions. So I tried googling “library routine called out of sequence”. A bunch of hits came back showing that it was an SQLite error message and that it is usually caused by a threading issue.
That seemed odd since, to my knowledge, I hadn’t made the app multithreaded yet. I was still doing everything in the main thread. Well, it ends up I was wrong. WebKit spins off threads when loading a WebView and my URL protocol was being called in a background thread. In it I was using the main thread’s NSManagedObjectContext to load the data being displayed. Doing so is fine if everything was running in the same thread, but CoreData doesn’t like threads unless each on has its own NSManagedObjectContext. Creating a new NSManagedObjectContext in the protocol’s class fixed the problem.
So there were two lessons that I can come away with from tonight:
1. If I run into any “library routine called out of sequence” messages I know I have a threading issue with CoreData and need to check what thread and with which NSManagedObjectContext the work is being done.
2. NSURLProtocols are being processed by WebKit in background threads and that I need to watch out for threading issues while writing one.