As I mentioned at the INetLib programming session at PalmSource 2000, here are some notes about VChat, the program that I and others at Veriprise worked on and distributed at the show. Briefly, VChat is a INetLib-based group messaging program, that provides an interface similar to IRC. The limited version we had at the show supported one channel of conversation, user nicknames, and some neat refresh methods on the Palm VII/VIIx. It won one of the PalmHack IV awards at the show, in spite of parts of it being written ahead of the conference and it being potentially useful. First, I'm not going to able to distibute any source code. The codebase is proprietary to Veriprise Wireless, my employer, and it looks likely that we'll commercialize and enhance this system soon. The core of VChat and the other thick clients for the Palm that we've produced is a class called VMPConnection. This acts as a wrapper around INetLib handling formatting of commands going to our server and the user interface while communications are active. A VMPConnection object is created during application start time, and it keeps an open handle to INetLib during the entire execution of the program. VMPConnection also has a set of modifier methods that set the URL for which to connect, timeout settings, and the title for the status dialog. Actually making a connection with the class launches into a special modal dialog running its own message loop. This code calls INetLibGetEvent, handles events for the form, updates the status display to tell the user what is happening with retrieving the data, and placed the data into a handy MemHandle for later consumption by the application. In addition to VMPConnection, we also had a VMPParser class that would handle disassembling the response packets from the server. It was a class that took a memory handle, would go through and URL decode each string, turning the delimiters into NULLs and building an array of offsets to the start of each string within the response. We setup a simple client-server protocol for VChat to talk between the Palm and our Veriprise Wireless Platform server. The commands supported were REG (Register User), GM (Get Message), SM (Send Message), and GI (Get Info). All of these commands included the device's ID for identification, along with the required parameters, all separated by ampersands. REG is used to setup the intial user account, and its also used to reregister later if your program is reinstalled or if you want to change details like your email address or hometown. The GM and SM commands are implemented similarly. The concept behind fetching messages is that each message is stored with an increasing ID number in the database. When you talk to the server, you tell it the largest message number known by the Palm client, and the server will start sending new messages starting at the first message it knows after that number. SM also adds a new message to be added to the database, the one the user typed into the application. The GI command was implemented in the client program, but it didn't get into the server in time for the conference. This command would get information about another user on the system, and we were planning on using it to allow you to email directly to a poster of a message. The user interface for VChat was originally written in C, but large parts were later adapted to into C++. Since this application was designed to promote Veriprise at the conference, it always went to a welcome screen on startup. For new users, this would explain the application, give the user an opportunity to launch WebClipping to visit the Veriprise website, and invite the user to register. Once you had registered, the welcome screen for future launches became a reminder of who wrote the program along with a display of the information you sent during registration. Once you'd passed that screen, you were in the conversation form, the heart of the application. In the version distributed at PalmSource, this was a simple form with a gadget, an attached scroll bar, a "send" button, and a "refresh" button. The gadget was rendered by a C++ class called MessageListView which rendered a window onto the list of messages using custom drawing code. To do this, when the message list changes, I recompute a cache of how many lines each message takes when displayed, then use the total height of all the messages to set my bounds on the scroll bar. Then, based on the scroll position, I figure out the first and last message displayed, set a clip region for the gadget, then draw all of those messages, relying on the clip region to prevent text from appearing above and below my gadget boundaries. Using a gadget to position this window provided lots of flexibilty in designing the user interface. I also had an event handler in my MessageListView class which gets called from the form's event handler which is what I used to handle clicking on messages for my aborted Get Info functionality. The other really cool piece of this app was how I did automatic refresh. INetLib provides no mechanism for having data "pushed" to the device, so you have to poll the server to find out if there are newly posted messages. I'd thought about using an alert to have the system refresh itself on a time schedule, but that really doesn't mesh with how the Palm is used, since if the device was turned off, the user wouldn't care if the messages were current -- she only cares when she's actually using the device. So, I added code to intercept the vchrHardAntenna character so if the user is in the application and he raises the antenna, I do a refresh then. This allows "Star Trek" mode as I call it, since you flip up the antenna and immediately start communicating, just like the communicators in ST:TOS. When this mode is on, I also do a refresh upon entering the conversation form when the antenna is up. This code is harmless on non-VII/VIIx devices, but it really improved the user experience with the appropriate hardware. Another very useful feature was integrating Aaron Ardiri's "Beam Myself" code he posted here before the conference. This made sending the application to other people over IR quick and easy -- I even handled vchrSendData to I could just make one grafitti stroke to send the application away. One bug that was pretty tricky: when the server misbehaved (as it did for registrations where the user left off their hometown or email address), it would return a error code which got translated into an internal network error, but with status code 0. I was directly calling ErrAlert with that code without checking to see if it really was a system error, so sometimes I called ErrAlert(0). This would produce a dialog saying just "Mem"; I suspect this is because the memory error base is at 0, but no errors actually start there, so we're just getting a prefix. Once I realized what happened, it was pretty easy to modify the error handling to better report server problems. So, if you got the program at PalmSource, be aware that the server will be going down very soon -- it was on a test machine which is being repurposed. I'm pushing internally here at Veriprise to have a public version of this application (along with a dedicated server) made available next year for everyone to use (with secure and enterprise-tailored versions being for sale to Veriprise's customers, of course)... we'll have to see if management buys this idea. My team and I had a lot of fun developing this, and even more fun using it at the show, so we don't want to see it go away either. Thanks especially to Eric Lyons, who did most of the forms plus the initial version of the message list display, and to the members of the Veriprise server solutions team in Atlanta who worked hard over the weekend before PalmSource to get our chat server online and debugged. Without their hard work, it would have been impossible to test and deploy in such a timely manner. -- Ben Combee Veriprise Wireless <http://www.veriprise.com> -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
