Compartilhar via

The Journey of the Lunch Launcher: Part 8 - What did I learn?

  • Artigo

Part 1 - The origins of the 'lunch launcher'
Part 2 - MEDC 2007
Part 3 - Managing the Transport
Part 4 - Sending messages
Part 4b - The output channel
Part 5 - Receiving messages
Part 6 - Processing messages
Part 7 - The Lunch Manager

Now that we have seen the story of the Lunch Launcher, from Roman's original introduction, through my journey implementing the MEDC 2007 demo to today's current version, it is time to take a step back and look at what I have learned.

Store and Forward Messaging is REALLY cool
The introduction of Store and Forward Messaging in version 3.5 of the .NET Compact Framework was the key to getting the Lunch Launcher from idea to reality.  By leveraging the email accounts that we all have, devices have become addressable and applications like the Lunch Launcher have become possible.

What started as a dream (being able to coordinate lunch with friends, no matter where they may be) has become a reality thanks to Store and Forward Messaging and the Windows Communication Foundation.

Windows Communication Foundation code is very reusable
When I first started working on the Lunch Launcher, I thought I would be writing a significant amount of message type (invitation, reply, etc) code.  I started with separate implementations for sending and receiving each type of message.  After reviewing the code, I found that there was a very high level of similarity in each implementation.  So much similarity that I was able to merge all three into a set of generic methods.  This consolidation has helped to eliminate code issues and to make them easier to fix (one place instead of three).

One way communications can be challenging
When working with traditional two way communications (request-reply model), you get rapid feedback as to whether or not the message was received and whether or not the task succeeded.

One way communication is different.  You need to implement a stateless programming model.  There is no built-in acknowledgement of receipt, nor is there a confirmation of task completion.  There are both benefits and challenges to these one way communications behaviors. 

The primary benefit of one way communications is that you get true asynchronous communications.  The sender and receiver can go offline at any time and the communications will still go through (once back online).

The primary challenge is knowing when the other side receives the message.  Since there is no way of knowing when a device will come back online, there is no way to accurately gauge the communications latency.  I won't go into detail here, as this can become a long discussion.

As mentioned earlier, there is no receipt confirmation or results transfered in one way communications.  To get this data, applications and services will need to engage in additional one way communications (in the reverse direction of the initial transaction).  As with the original communications, this too has the same challenges and benefits.

Is this the end for the Lunch Launcher?
No.  The Lunch Launcher will continue to evolve.  I still need to implement the voting system and clean up some fit and finish issues as well as a thorough round (or twelve) of testing, testing, testing.  In fact, I plan on using Visual Studio 2008's Unit Testing feature to implement a suite of tests for the LunchLauncher.Logic assembly.

I also hope to give it a much nicer looking user interface.  What I have is functional, though I see much room for improvement.  The first step is to create a Windows Mobile Standard / Windows Mobile Smartphone version and then to borrow the eyes of some of my aesthetically minded friends with the hopes that they will have some ideas for a nicer look and feel.

Thanks for reading
It has been a joy to not only write the Lunch Launcher, it has also been great to share my experience with you -- from MEDC 2007 to this site. 

Take care!
-- DK

Disclaimer(s):
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.

Comments

  • Anonymous
    November 13, 2007
    Great series! Could you please post the full code somewhere?

  • Anonymous
    November 29, 2007
    An Introduction to WCF for Device Developers Chris Tacke OpenNETCF Consulting, LLC November, 2007 Download

  • Anonymous
    March 20, 2009
    MSDN文档 WindowsCommunicationFoundation(WCF)Developmentandthe.NETCompactFramework http://ms...