iSync for Motorola V197
December 12, 2008
Apple now provides a tool to help you write phone plugins for iSync, but it does not work. Long story short, I tried to use it to create a script, and it didn’t work.
The standard explanation for this is that, of course, the user is a dummy. However, this user is not usually a dummy, and what I noticed was that the application kept asking me to answer questions that I had no way of knowing the answers to, and in the one case where I did know the answer (because I asked the phone, and copied its answers) the application didn’t like my answers, and reset them.
As further proof that the problem lies in the application, not the user, I did in fact create a script for syncing my phone. I took an existing script, modified it in the standard way (s/V195/V197), laboriously created a TIFF file for my phone’s icon (seriously, took a photo of the phone on top of green surface, selected all the green, and embarked on a Gimp McGuffin to figure out how to make the green transparent — try it sometime, it’s like a bleeping treasure hunt), and then, copied in the magic response strings from the phone (scroll down, it’s there, I used GSM Remote to feed it the AT strings). Put the phone plugin in my Library/PhonePlugins directory, fired up iSync, and shazam, I’m sync’d.
The tool is willing to test my script for me, and claims that my script is defective, and is not even capable of connecting to the phone. I am a tool-writing guy myself, and this sort of thing is ultimately depressing. When you hear about some guy using vi, or emacs, (or, perish the though, “ed”) instead of some fancy IDE, it’s because they’ve been burned one time too often by a know-it-all tool, that lies to you, has crap documentation, fails inscrutably, and cannot even justify itself when you ask it what the problems are.
David 1, Tool 0. Remember, the purpose of the tool is to help me get the job done, and it didn’t — it never succeeded, and the computer equivalent of rocks and sticks got the job done faster, and apparently correctly.
Update — after cribbing carefully from the Motorola K1 plug-in, I got it all the way to recognizing the phone (I replaced some arrays of single string, with plain old string). And now, says the Plug-in Maker, “This phone cannot be tested with this plug-in”. Hel-lo? Is that all the information you can give me? Is this error message going to help the user (me) get past the problem? If only someone, somewhere, could write down some Human Interface Guidelines, that would guide developers in the better construction of error messages, so that I would not waste time at this unproductive impasse. Golly, looks like that book is already written, sitting on the shelf right next to me — the Macintosh Human Interface Guidelines. “Macintosh” — I wonder if that has anything to do with “MacBook”? Do you suppose it is the same company? Surely not, that would be such an embarrassing mistake. On the other hand, maybe books are just too expensive and take up too much space; times are hard, after all. I guess I could understand that, if the book were not available for free PDF download.
If you need the plugin yourself, click the phone, unzip, and move it to Library/PhonePlugins/ (either the main Library, or your own Library).
Oh yeah, this is for USB syncing. You want Bluetooth, you figure it out yourself (but please let me know the incantations, if you do).