Scott Gruby's Blog

Back when I started writing ReceiptWallet, I wanted to add scanner support and the easiest way looked like I could use Apple’s Image Capture (ICA) framework. This worked quite well for the first scanner I tried, but the second one only scanned in black and white or had some other problem. So, I gave up on that, learned enough TWAIN to get ReceiptWallet working with most scanners that had TWAIN drivers. I was quite content for 1.5 years (except for the crappy scanner drivers and crash reports I regularly received). Last week I was contacted by a developer who asked me if I was going to support ICA because some newer scanner drivers were going to be written around ICA. I already had ICA code in ReceiptWallet (I actually tried again right before ReceiptWallet 2.0 was released), so I took a look at it. Well, there is either a problem with my scanner or ICA in Leopard (10.5.2) as I can only scan in black and white. Furthermore, there is a really simple function, ICAImportImage, that should reduce the amount of work I have to do and presents a standard user interface.

There are a few major problems with this interface. The whole area near Scan To Folder is unnecessary if it is called from within an application. I don’t want the user to specify where it goes, the format or automatic task. The second major issue is if I change Scan Mode to Flatbed (even though I have a sheet feed scanner), parts of the UI dim and I have to quit the app (same thing happens in Apple’s Image Capture application).

So while this is great in theory (I’ve seen one app use this and apparently not care about the issues), it is a poor user experience in any app other than Image Capture. I’ll write up a bug for Apple on this, but who knows when it will get fixed. As for my other issues with ICA, I opened an Apple DTS incident and some of my issues were confirmed as bugs. Wow, that makes it almost impossible to use ICA as I found several bugs in just a simple use of the API.

Will Apple fix ICA? Hopefully. When? I don’t have any clue. My hope is that it is sooner rather than later.

It seems to be a recurring topic here on my blog, threading. I was asked to look at a problem for a client yesterday and discovered a very subtle threading issuing (I actually didn’t create it, one of the other people on the project created the problem when he added some code). Basically in order to show progress while the app is doing stuff, some code is executed on a separate thread. However, the main thread basically spins in a loop using something like:

while (threadRunning)
{
	NSDate *newDate = [[NSDate alloc] initWithTimeIntervalSinceNow:0.05];
	[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:newDate];
	[newDate release];
}

The application uses CoreData for managing data and the second thread accesses the CoreData store. You would think that the above code blocks the main thread from doing anything while the second thread is running, but like my issue with NSTask, the main thread is actually doing something. In this case, the UI is bound using Cocoa bindings to the managed object context and the secondary thread was also using the same managed object context. As explained in Apple’s docs on Core Data multi-threading, you could get a deadlock when 2 threads are accessing the same managed object context at the same time. Bindings hid the fact that they were talking to the managed object context. I should have realized this, but I didn’t.

Will I ever learn about how to get threading right?