Good API ideas gone bad

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.

Threading rears its ugly head, again

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?

Are software bundle deals just marketing hype?

I've commented on the past about MacHeist bundles and eventually decided that the bundles are not a bad thing with the exception of potentially decreasing the value of individual pieces of software. Last week, MacUpdate Promo started a new bundle deal with some interesting apps and Parallels being offered up if certain sales goals are reached. That's fine. Even though I have Parallels and Hazel, I bit as some of the other pieces looked interested and I like collecting software (odd hobby, I know). Typinator and MenuCalendarClock are already in use daily.

So now I come to my point on this entry. The MUPromo site indicates that X units have to be purchased to "unlock" Parallels. However, over on several other websites, they're running the ad that appears to the right. If you saw that ad, you would expect to get Parallels and 9 other apps as indicated. So, unless MacUpdate wants to be accused of false advertising, Parallels and the other 9 apps listed on their site will be included. Why the whole charade over unlocking based on sales numbers? Just hand over the applications and be done with it. So, in actuality, I should have all 10 applications today as indicated in the ad, but I have to wait until MUPromo decides that it is going to "unlock" all the apps.

(No one has asked me to be part of a bundle for ReceiptWallet and after this post, I'm not sure anyone will :-)).

Hacked Serial Numbers

In the past, I've written about software piracy, registration codes and catching users with pirated serial numbers. As part of the latest update to ReceiptWallet, I added some additional checks for invalid registration codes (read, pirated or hacked). One of the simplest ways to deal with this would be to have ReceiptWallet check in with my server to validate the code, but I don't like that idea. What happens if my server goes down or my company goes away? Users can no longer use the software, so I avoid that method. This morning, after I released a new version of ReceiptWallet, one of the first messages I received was a user saying that there was an error with his serial number. This meant one of two things; the user was given a refund and is no longer eligible to use the software or he used a hacked serial number. After a little probing, he admitted that he didn't remember purchasing the software and wanted to know how to buy it. I didn't outright accuse him of using a hacked serial number, but I suspect he figured it out pretty quickly.

As with most serial number schemes, there is going to be no way to stop those that are serious about pirating. I have no plans on spending a ton of time on thwarting pirates, but an enhancement here and there doesn't hurt.

I wonder how many other email messages I'll get about invalid serial numbers.