Now that Apple has announced the immediate availability of Intel-based Macintoshes, the developer community needs to get serious about adjusting our projects so that they build and run natively on the machines.
For a long time, Apple has made available the required SDK for “dry running” our projects as Intel-compatible builds. Some developers even took Apple up on the “transition kit” systems, which put Intel machines (though quite unlike the shipping units) in the hands of developers from a very early stage.
A common thread on the mailing lists seems to be the unhappy scenario of essentially having ones own code ported and ready to test, but being held hostage by the slowness of another library upon which you depend. When the library is open source, it’s easy enough to take responsibility for it yourself. Get your feet dirty and port the dang CurlHandle class over yourself! But many of us (perhaps unwisely) have gotten ourselves into situations where we depend upon the compiled code of others in our shipping products.
Kagi’s KRM module allows Kagi vendors to present users with an integrated purchasing dialog. It’s essentially a single dialog that takes the user’s financial information and ships it off to a Kagi server for further processing.
For those of us who have been using the Cocoa-specific version of KRM, the wait has been long for a universal version of the libraries. In fact, the wait will be very long. It doesn’t appear that Kagi is planning any further updates to the Cocoa-specific module. Instead, we’re offered the “Zonic KRM” module, which is a straight-C CarbonEvent based solution.
At first, I was annoyed by the presumption that Cocoa developers should have to pull up roots and switch to a new library with a new API (a straight-C one, to boot!). But after downloading and using the Zonic KRM solution, I am happy to report that it’s an overall cleaner and easier to use module than the previous Cocoa-based framework. As a single library archive and associated header file, this requires none of the linking and packaging headaches of the Cocoa KRM package. The API is straightforward and offers few opportunities for careless error. Even the UI is, ironically enough, improved over the Cocoa version.
The only major snag I’ve run into is that the Zonic purchase window doesn’t appear in the floating layer as the old Cocoa KRM did, and seems to suffer some activation issues when invoked from my LSUIElement application. These types of problems were what originally led me to choose Kagi over eSellerate, whose Carbon-based solution had the same problems. Hopefully these can be resolved with Kagi – I’ll have to investigate. [Ed. Note: These issues were more or less mistaken impressions, and are somewhat elaborated upon in updates at the end of this article]
All the improvements will mean little, however, to Carbophobic developers who have grown accustomed to avoiding most APIs that don’t fall firmly into the Cocoa space. I don’t blame them. If I didn’t already know this Carbon stuff, I probably wouldn’t want to sidetrack my rapidly progressing project to figure it out, either.
In the spirit of helping these developers out, and with the somewhat selfish goal of encouraging as many Intel-native apps as possible by the time my MacBook arrives, I’m posting a very simple demo project that shows how you might integrate the Zonic KRM modules into a Cocoa application. For this example, I’ve taken the attitude that you want your exposure to Carbon to be brief, handing back control to a “sane, Cocoa world” as soon as possible. The gist is pretty simple:
- User pushes a button, invoking an IBAction method.
- Action method installs a Carbon event handler for Zonic “I’m Done.”
- Action starts a modeless Zonic registration dialog.
- Zonic finishes and issues the Carbon Event.
- Callback receives event and passes event-completion structure back to Cocoa.
[Ed. Note: It has been pointed out that using the “modal” Zonic dialog is exceedingly simple, and doesn’t require any use of the Carbon event API.]
Note that since I’m not sure I have the right to redistribute the Zonic library and header file as-is, I’m not including them in the sample project. You’ll have to download them directly from Kagi.
I hope this proves helpful to some of you.
Update – My LSUIElement problems seem to be worked around by using the modal version of the Zonic dialog API.
Update 2 – Wed, 1/11/2006, 1:40PM EST. I’ve updated the sample project to include demo cases for both Modal and Modeless variants of the Zonic KRM dialog.
Update 3 – Wed, 1/11/2006, 1:55PM EST. Another update to the sample – should dispose of the Zonic result structure when done with it. Also, it should be noted that the “LSUIElement” related problems alluded to above are more general. It appears that Zonic KRM’s modeless dialog is not well suited to being displayed while a Cocoa NSPanel of any kind is being displayed.
Update 4 – Thursday, 1/12/2006, 1:55PM EST. Incorporate memory leak fix suggested by Kirk in the comments.
Update 5 – Friday, 1/13/2006, 10:48AM EST. Friday the 13th Special! Kagi and Zonic have kindly agreed to let me include the Zonic library and header file in the demo project, so it should be buildable as soon as you download it, presuming you have Xcode 2.2 installed.
Update 6 – Tuesday, 2/21/2006. I meant to point this out earlier, but forgot. There is a problem in the 1.0.4 Zonic release that causes it to crash on 10.2 deployments. An ingenious workaround was discovered by another Mac developer and shared with me via Kagi. Simply lipo the PowerPC code from Zonic 1.0.3 with the Intel code from 1.0.4. I’m using this solution in the interim and it gives a solid fix to the problem the Zonic 1.0.5 release is ready.