Click here to Skip to main content
12,747,162 members (28,026 online)
Click here to Skip to main content
Add your own
alternative version


5 bookmarked
Posted 1 Apr 2010

Inter-process Mediator

, 1 Apr 2010 CPOL
Rate this:
Please Sign up or sign in to vote.
Imagine for a second that you are writing an application like Outlook… let's call it MiMail.exe! This application is very basic and has 3 views that are relevant to me! I want to be able to see my mail, contacts and calendar!

Imagine for a second that you are writing an application like Outlook… let's call it MiMail.exe! This application is very basic and has 3 views that are relevant to me! I want to be able to see my mail, contacts and calendar! There are also 3 specific tasks that I want to be able to execute: new mail, new contact and new appointment!

At any given time, I only want one instance of this application running but I want to be able to execute these tasks by using the command line arguments, i.e.:

MiMail.exe /mail
MiMail.exe /newContact

I am going to use a variation of the mediator pattern to facilitate the inter process communication via named pipes!

Mediator Pattern

The mediator pattern, one of the 23 design patterns described in Design Patterns: Elements of Reusable Object-Oriented Software, provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior.

Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes.

With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

Ok, so variation is maybe an under statement… more like abuse the mediator pattern!

Named Pipes

In computing, a named pipe (also known as a FIFO for its behavior) is an extension to the traditional pipe concept on Unix and Unix-like systems, and is one of the methods of inter-process communication. MacOS calls it a socket, which should not be confused with a TCP socket. The concept is also found in Microsoft Windows, although the semantics differ substantially. A traditional pipe is "unnamed" because it exists anonymously and persists only for as long as the process is running. A named pipe is system-persistent and exists beyond the life of the process and must be deleted once it is no longer being used. Processes generally attach to the named pipe (usually appearing as a file) to perform inter-process communication (IPC).

A good friend and fellow MVP, Mario Lionello, helped me out getting the asynchronous named pipes to work! I included his MaLio.AsyncPipes library!!!

Here is my updated App.xaml.cs:

public partial class App : Application
   const string appName = "MiMail";

   private void OnStartup(object sender, StartupEventArgs e)
      if (SingleInstanceManager.IsApplicationRunning())
         foreach (var arg in e.Args)
            Mediator.Notify(appName, arg);


      Views.MainView view = new Views.MainView();
      view.DataContext = new ViewModels.MainViewModel();

MiMail is using a very simple mutex to detect if there is an instance of this application running. If the application is already running, use the Mediator to notify the listeners that a new instance was started and pass the command line arguments as messages!

Now I can just wait for new messages!

mediator = new Mediator(appName);

mediator.Register("contacts", ShowContacts);
mediator.Register("calendar", ShowCalendar);
mediator.Register("mail", ShowMail);

Here is an example of the Action<>:

void ShowContacts(object message)
        new Action(() => 
            viewHost.Children.Add(new ContactsView());

And that is it!!!

Launching “MiMail.exe contacts” will call the ShowContacts action!!!


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

South Africa South Africa
No Biography provided

You may also be interested in...

Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.170215.1 | Last Updated 1 Apr 2010
Article Copyright 2010 by rudigrobler
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid