CaseDetective 1.3 took a little longer than I hoped to develop, partly because I took some time off to recharge my batteries after CaseDetective 1.2, but also because of some painful obstacles I had to overcome during it’s development.

This is the first post in a short series of “Lessons Learned” from development of CaseDetective 1.3 for FogBugz.

The first, and most asked for feature that I needed to develop for CaseDetective 1.3 wasn’t even a real feature; Universal Binary for the Mac OS X version.

A Universal Binary version was long overdue, I would have loved to have got one out for v1.2, but REALbasic hadn’t got that functionality stable by the time I started development, and more to the point, the eSellerate Universal Binary REALbasic plugin wasn’t anywhere near ready. As I rely on this plugin for validating serial numbers and for in-app purchases, this “feature” had to slip to v1.3.

Unfortunately the Universal Binary eSellerate plugin for REALbasic caused me a lot of headaches, which considering the Mac OS X users of CaseDetective are vastly outnumbered by Windows users, is very frustrating.

The first, and most annoying problem with the eSellerate UB plugin was that it wasn’t cross-platform, meaning I couldn’t compile CaseDetective for both Windows and Mac using the same eSellerate related code; I had to continue to use the old Integrated eSeller plugin for compiling the Windows version. And to add insult to injury, the old plugin would not work with the latest REALbasic IDE without being converted to the latest plugin format (a tool for this is provided with REALbasic), and even so, seemed to clash with the new plugin so that you had to compile for Windows and Mac as two separate steps (even when using #if to target the OS specific code). I resorted to making everything I could an external item and creating a copy of the project so that I had one project for Windows and one for Mac OS X. Each project referenced pretty much the same external items except for one module that included Windows or Mac specific eSellerate code, and ran each against a different version of the IDE so that the plugins didn’t clash. It worked, but wasn’t ideal for productivity.

The new eSellerate UB plugin for REALbasic was also different in operation to the old plugin, it used their “Embedded Web Store” framework, which used an embedded web browser in a window, and required setting up of a web store in the eSellerate admin panel. Now, I wouldn’t have had any problems with this change except that it required different handling of Stock Control Units (SKUs, don’t ask me why they use a “K”, I have no idea), which totally broke the way you setup the check for update functionality. Now I needed to update two areas of my eSellerate setup to cope with the Integrated eSeller used by the Windows version, and the Embedded Web Store (EWS) used in the Mac version. This is a recipe for disaster (although I think I’ve avoided disaster so far).

Also, unlike the old Integrated eSeller, the Mac EWS plugin needed a file to be copied into the app bundle after it was created, the old version didn’t require any extra files, it was compiled in and self installing.

Oh, and in the end I had to disable the in-app purchasing from the Mac version anyway because I found that if you tried to print the invoice shown after completing a purchase it totally hung the app and required a force-quit. Now, this may have been something that I did, but I’m stumped as to what that might be, seeing as printing the invoice had nothing to do with closing the window and returning to my app, so I’m pretty sure it’s a bug in the eSellerate plugin or EWS framework. When I found this bug I was about ready to explode, there was no way I was going to waste any more time in trying to find a workaround, so I just disabled in-app purchasing in the Mac version. Mac users will have to buy through the web store and copy their license details into the “Enter License” window, not a huge problem as most people seem to buy that way anyway, but still, it’s a shame I couldn’t use this convenient in-app purchasing mechanism which sets the user’s license details automatically on purchase completion.

I think version 2.0 of CaseDetective may just be using a custom serial number scheme rather than eSellerate’s own scheme, and then I won’t need to use any eSellerate plugins at all.

Don’t get me wrong, in general I like eSellerate, in all my dealings with them I have had superb support and have had zero problems reported to me by customers about their buying experience through them. It’s just that their REALbasic support has taken a serious nose-dive, which is unacceptable to me.

Lesson Learned: Develop your own license code scheme, regardless of purchasing mechanism.