Nothing to report

Nothing really to report. My project has been sidelined for about a month. I’ve got too much going on at work and home to spend any time working on the iPhone app. Building out the basement has got to take a priority right now.

I’m finding that the older I get the more singularly focused I am. I really hate multitasking. I’ve either just really gained an appreciation for focused work or I’ve lost my ability to multitask. I guess the result is the same. Plus it’s hard to concentrate with all these apple tablet rumors.

Using Predicate Builder

I started writing fetch requests and my mind began to remind me that I had seen something interesting about creating a NSFetchRequest using a GUI tool. I pulled up my data model in Xcode and fired up predicate builder. I knew there was a nice GUI way to generate the predicates without fussing with the tricksy predicate language. My problem was, “how to create a variable that I could use at runtime to substitute with a value. The answer was not immediately obvious. I stared for a while at the sheet below and tried various clicks to try and squeeze the functionality out of the screen below to no avail. Then I did a quick google search and came up with an interesting article. It’s a bit dated, but it provided a good explanation of the screen below and laid the secrets of the predicate builder bare. Behold the predicate builder tutorial! (*hint* right-click just to the left of the ”-“ sign)

Linking Error in Unit Tests

Surprise, Surprise, another inexplicable linking error after writing a test. This time there was an error that looked like this:

Undefined symbols:
“.objc_class_name_FolderSynchronizer”, referenced from:
literal-pointer@__OBJC@__cls_refs@FolderSynchronizer in FolderSynchronizerTests.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Thankfully, a good nights sleep caused the answer to come fairly quickly. I had forgotten about this, but I originally added the class FolderSynchronizer.m incorrectly. I was typing to quickly and accidentally created the file without the “.m” extension. I corrected it and everything built fine in my application target, but changing to the unit test target would cause the error above. I started down the path of checking what targets the file was assigned to and everything looked correct. It wasn’t until I expanded the unit test target and looked in the Compile Sources step that I noticed FolderSynchronizer.m was not listed. It was in the step above, Copy Bundle Resources. All I had to do was drag and drop it into the Compile Sources step and the test compiled and ran fine. I guess adding the file as a “normal” file instead of a “.m” file caused it to be treated as a resource and not source code in the unit test target.

Unit Testing with Objective-C

I’ve been enamored of late with the concept of Test Driven Development and have found it incredibly useful while working on my iPhone app. It has also taken a lot of time and more than once, I’ve thought about not unit testing and just coding as fast as my little fingers will let me. Every time though, there’s one argument that brings me back, and that is the argument of the courage that unit testing gives a developer when refactoring. I’m so new at this iPhone development that I am bound to make design mistakes. I know that if I have any hope of shipping a product, It will at some point need to be refactored and the only way I’ll be able to do that confidently is if I know that my application is being tested thoroughly. Therefore I continue to write tests.

I found an article that described how to write unit tests that use Core Data and I began using it. It can be found here. It was fine until I started trying to save the NSManagedObjectContext, and then it failed with the following error:

This NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation.

I thought my code was solid, but apparently my Core Data stack was missing something. What I did was create an in-memory persistent store as part of my Core Data stack. I simply added the line,

[coordinator addPersistentStoreWithType:NSInMemoryStoreType configuration:nil URL:nil options:nil error:&error];

to the entire chunk of code below:

-(void)setUp {
        NSMutableSet *allBundles = [[NSMutableSet alloc] init];
        [allBundles addObjectsFromArray:[NSBundle allBundles]];
        [allBundles addObjectsFromArray:[NSBundle allFrameworks]];
        managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles:[allBundles allObjects]] retain];
        coordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:managedObjectModel];
        NSError *error;
        [coordinator addPersistentStoreWithType:NSInMemoryStoreType configuration:nil URL:nil options:nil error:&error];
        managedObjectContext = [[NSManagedObjectContext alloc] init];
        [managedObjectContext setPersistentStoreCoordinator:coordinator];
}

Linker Errors On Unit Test Compile

I’ve sunk probably 16 hours into this problem, with no results. Today I finally bit the bullet and went to plan-C. Thankfully plan-C worked, plan-D would have involved gasoline, matches, and my MacBook. The problem as best I can explain it is this. It started when I was building a simple domain object, simple properties with an initWithDictionary:(NSDictionary *)dictionary method. I had created the object, wrote the unit test, and ran the test to be sure that my setup worked but my test should fail. Then I implemented the method, and ran my test hoping for a hole-in-one. What I got was about as useful as a hole-in-the-head. The compile failed with a vague error about my .octest bundle being linked to a file that was not available at runtime. I’ve tried everything, cleaning all targets, deleting the build directory, double-checking all of the linked frameworks and paths, and even removing and adding one-by-one my test files. Still no joy. The funny part was that when I changed the active target to my application target, the app would compile fine. To make a 16 hour story short, I created a new project and copied all of my resources and files into the new project. It took about 20 min. and worked great. I’m now ready to continue until the next inexplicable error. Who knew unit testing was this difficult.

Introduction

Well, I finally got around to creating a blog for writing down my experiences learning Objective-C and iPhone development. I’ll try to give back a little. The internet has been tremendously helpful and it would probably be a good idea to try giving rather than just take, take, taking.