How to fix: Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'executeFetchRequest:error: A fetch request must have an entity.'

If you get this error in your code that uses Core Data, chances are you have a typo or are using wrong names for your entities when you're preparing your NSFetchRequest objects. That is, the names in your code (some of it which is autogenerated by Xcode) do not match the names in your model.

For instance, I was following some code snippets in the Pragmatic iPhone SDK book and I had somehow ended up with the following lines:

// Create the fetch request for the entity.

    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];

    // Edit the entity name as appropriate.

    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Event" inManagedObjectContext:managedObjectContext];

    [fetchRequest setEntity:entity];

Here the @"Event" name was wrong, as my .xcdatamodel file was actually using the name @"Track" for that entity. Changing that name in the code to match the model fixed the issue.

A similar naming mismatch was on this line:

NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"timeStamp" ascending:NO];

The correct key for my model was @"name". There were other similar issues in the code.

One could argue that this is a shortcoming of the Xcode tool, as it fails to keep the names in the code generated by wizards in synch with changes in the model. As Core Data is a relatively new addition to the iPhone SDK, it's likely this will be improved in future versions.

free chapters from Dynamic HTML: The Definitive Reference, Third Edition

I've been using Danny Goodman's book as a reference material for my DHTML development work. Up until recently I had access to an HTML version of the book, provided by Safari. That format was pretty useful in looking up things, as they provided a hyperlinked index. Then they moved to a paper-like format which makes finding things much tougher. In the process they also dropped a few chapters. These chapters, unlike the bulk of the book, were not referenceware, but they were a very good coverage of the main topics in DHTML development. In fact, their coverage of events were the best I found in available literature. You can imagine my dismay when I discovered that exactly those chapters were dropped from this latest edition of the book.

The good thing though is that those chapters were made available online for free, as an online supplement reachable from the book's page in Oreilly's catalog.

memory leaks in open_handle_to_dylib_path and UIKeyboardInputManagerClassForInputMode

If you're developing an iPhone app that uses UITextField objects and you're rigorous enough to check for memory leaks using Instruments, chances are you'd discover some leaks in UIKit and CoreGraphics libraries, stemming from some allocations done in dyld::mkstringf, called from dyld::loadPhase5.

According to some reports found on the web, it seems that this is a bug in the tools from Apple, and it appears only on the simulator, not when testing on the actual device. So you could safely ignore it. In any case you couldn't do anything about it, as the traceback leading to the leak goes through code outside of your control, that is, unless you happen to work for Apple :).