Programming

Clean SOAP

by

I gave up on using AppleScript Studio for my Installer front-end application. AppleScript’s SOAP implementation seems to be broken. I ended up writing it in Objective C instead, using Web Services Core. It isn’t that much more difficult than writing it in AppleScript, and I’m able to use the window layout I already created for the AppleScript version. By encapsulating all of the web service method calls into a single class, I’m able to keep the code fairly simple.

AppleScript and dirty SOAP

by

I’m writing an AppleScript Studio application which needs to call some SOAP web services before running an installer. Somehow AppleScript seems to be adding a bogus namespace to the SOAP call.

The method I want to call should look something like this (actual names changed):

<RegisterUser>
<UserData>xyzzy</UserData>
</RegisterUser>

Instead, the request looks like this:

<m:RegisterUser xmlns:m="http://myserver/mynamespace">
<UserData>xyzzy</UserData>
</m:RegisterUser>

The AppleScript code looks pretty standard:

	tell application "http://myserver/endpoint" to¬
		call soap {method name:"RegisterUser", ¬
			parameters:{|UserData|:"xyzzy"},¬
			SOAPAction:"http://myserver/namespace/RegisterUser", ¬
			method namespace:"http://myserver/namespace"}

I have no idea where the bogus ‘m’ prefix came from. This same method is being called successfully from .NET under Windows.

Working on Mii Transfer

by

I’ve been trying to use Jasen’s branch of WiiRemote Framework from Subversion which integrates my code and is supposed to make it more reliable on PowerPC. Unfortunately I found that it makes the connect much less reliable, at least on my MacBook Pro. I fixed the problem with Miis other than the first one being corrupted, but I still don’t have sending Miis working.

Mii Transfer progress

by

I haven’t had a chance to do much work on Mii Transfer this week. but I’ve changed the way I read Mii data to read the entire 750 byte block (+ CRC bytes) into a buffer and then simply copy the requested Mii from the buffer. I also fixed the reported bug where Miis other than the first one will be corrupted.

The new method readMiiData will read that entire block. If you call getMii: without first reading the buffer, it will request a read and return nil, with the gotMii: delegate method getting called when the block is completely read. If the Mii data block is in memory, it will return a pointer to the requested Mii and the delegate method won’t get called.

Writing Miis still doesn’t work, though. You can only write 16 bytes at a time. I’m sure it returns some kind of acknowledgment when the write completes, but I’m not sure how to handle it.

Technorati Tags:
, , ,

More about Miis

by

I’ve been looking at the code for sending Miis to the remote and I discovered it’s not as simple as receiving a Mii. You can request a single Mii, but you can’t send only a single Mii – you need to send the entire block of 10 Miis with the properly calculated CRC. That means I need to read all of the Miis, overwrite the one I want to send, calculate the CRC and send either only that one Mii + the CRC or the entire block.

Mii Transfer 0.1a fixes PowerPC compatibility

by

I just released Mii Transfer 0.1a to fix the launch problem on PowerPC Macs. There are no code changes, I simply linked it with a universal build of WiiRemote framework. Intel Mac users don’t need to update.

I also added a troubleshooting section to the readme file. The major problem on G4 Macs (which is actually an issue with WiiRemote framework) is pairing problems if the remote is also added in Bluetooth settings. Make sure the Wiimote is NOT connected in Bluetooth preferences (it will appear as a device named “Nintendo RVL-CNT-01”). If it does appear, disconnect and delete it. Make sure the Bluetooth setup window is CLOSED before you attempt to connect. If the connection fails, quit and relaunch.

It's Mii!

by

After I created my Mii, I wanted to get it on my Mac so I can use it as an avatar in other forums. I found that there are several Mii copy & edit utilities for Windows but none for Mac OS X, so I decided to hack Mii support into WiiRemote Framework. For anyone unfamiliar with the Wii, the only way to currently obtain the Mii is by saving it to the remote and extracting it from the remote.

The Wii Remote is actually a smart Bluetooth device, so it can be used with any computer than supports Bluetooth. It isn’t simply a controller; it has an onboard processor and memory. Lots of information is available at WiiBrew Wiki.

It turns out that Mii data isn’t actually stored as a graphic. Instead it’s a 74 byte structure describing all of the features & attributes of the Mii (hair color, facial features, etc). There are sites like Mii Plaza which lets you upoad & share binary Mii files, so I’ll just be saving it in a compatible format rather than displaying & editing the Mii.

Like most Bluetooth HID devices, rather than reading the data directly from the Wii remote, you send a data request, and the data is returned in a L2CAP channel message. Since it can only send a maximum of 16 bytes in a message, the Mii data is sent in several messages, which I need to assemble. Since the L2CAP channel is used for other data as well, we need to look at the memory offset to determine that we’re receiving Mii data.

Right now I just hacked an extra button into DarwiinRemote to obtain the first Mii. I plan to make a more flexible stand-alone Mii utility.

Technorati Tags:
, ,

Get rid of dialog boxes

by

Coding Horror notes that most users simply ignore dialog boxes and simply dismiss them without actually reading them or understanding what they mean.

This is a result of the overuse of dialog boxes. According to the original Macintosh Human Interface Guidelines, a dialog box should only be used for an exceptional condition that requires immediate user action. Over time this rule was ignored and most software now puts up a dialog box for every little thing and in most cases it’s inappropriate.

Users become desensitized to dialog boxes since they appear so often and simply dismiss them immediately. Windows Vista has made the situation worse with the frequent security confirmation boxes. After a short time, users simply keep pressing ‘accept’ without understanding the situation.

Sheets in Mac OS X are a step in the right direction, since they appear in the window they apply to and are related to the user’s current activity, such as printing or saving the document.

As the article points out, software updates are a prime area where alerts can be eliminated. The user shouldn’t be prompted for important security upgrades; they should simply be downloaded in the background. If a reboot is necessary, they should simply display an icon in the menu bar to notify the user. Most operating systems have such an option. It should be made the default, since that’s the best option for unsophisticated users. More advanced users can change it.