In part 1, I introduced the lunch launcher. Today, I’m going to talk a bit about the preparations for the “world premier” of the lunch launcher from MEDC 2007.
Before getting started, I set out a few goals:
- Provide an introduction to the Store and Forward Messaging feature of .NET Compact Framework v3.5
- Demonstrate point-to-point device communications via Store and Forward Messaging
- Implement invite / reply functionality (voting and destination notification were not a goal for the demo)
- Minimize duplicate communications code where possible
- Use additional .NET Compact Framework v3.5 new features as appropriate and/or interesting
With the goals defined, I sat down to write my vision of the lunch launcher. I installed an almost beta 1 release of Visual Studio 2008 (then node named ‘Orcas’) and created a Windows Mobile 6 Professional project.
The first thing I wanted to be sure to do was to reinforce some of what I would be talking about in my Thursday session — GUI-Logic separation. While not split into separate assemblies for MEDC (they are split now) the user interface and business logic (aka the engine) were contained in a collection of classes across two namespaces.
My next goal was to design the communications to be as simple, and re-usable as possible. Though I did not completely achieve this in the MEDC demo, it has since been accomplished. I will talk about the changes between the MEDC and current designs in a later installment.
The communications required by the lunch launcher fall into three transactions: invitations, invitation replies and destination (where to meet for lunch) notifications. I implemented separate channel pairs (send and receive) for each transaction. By designing this way, each input channel knows how to receive exactly one message type, no complex “what type of message did I receive” logic. Similarly, output channels need only know how to send a single message type.
For the sending of the messages, I discovered that the code was nearly identical for all three of my transactions. The only differences were the message type and the name of the channel that would be receiving the message. This got me thinking about encapsulation. As a result, I created an object that contained all of the required Windows Communication Foundation objects and a method to send the message. This was very effective and allowed me to fix issues in all three channel pairs with one code change.
For the receiving of messages, I actually had three copies of very similar code. Since this was an introductory demonstration, I elected to not factor the common code until after MEDC. Instead, I used the duplicated code to illustrate how similar the transactions actually were.
Remember when I said I installed an “almost beta 1” release? I went into panic mode when I installed the final beta 1 build and found that I could not build my application (see Mark‘s post for the why’s). The issue identified (and worked around for the trip), I went back to fine tuning the demo.
Tuesday morning, Las Vegas: In the final morning session of the first day of MEDC, I took the stage in what I called “the big room” (as opposed to the “really big room” where the keynote was held) to present in front of my largest audience to date. The room held about 400 people and I was told that there was standing in the aisles and in the hall (wow!).
When it came time to unveil the lunch launcher, I wondered (not for the first time) if I had too much coffee as my nerves were on high alert. Demonstrating pre-release software live on stage is a scary thing. Any of a number of little things could easily go wrong. Fortunately for me, things went extremely well. Even the delays waiting for message delivery through the server were minimal — so minimal, in fact, that I was still explaining what was occurring when the messages arrived.
The lunch launcher was now officially real. 🙂
With a successful demonstration of peer-to-peer social messaging complete, it was time to show how it worked. Since this post has gotten a little long winded, I will save that discussion for the next installment.
This posting is provided “AS IS” with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.