Sunday, December 12, 2010

Comprehending WPF. NetMonitor

About a month ago I wrote a post about the overall complexity of WPF technology, steep learning curve and other things that might be perceived as roadblocks, especially for novices or old-school WinForms programmers.

After that I had several intensive discussions with my colleagues on the subject and they told me one important thing, the main idea was that the technology just seems to be overcomplicated, especially from the first look, when you don’t see the overall picture how it is built, how it works and how it should be used. Another thing that is worth mentioning is that the architecture is reasonable, because it gives a UI designer the required flexibility and power, which WinForms just can’t provide and this very fact can only be seen on complicated UI scenarios, not on simple ones.

As a result, they persuaded me to take a closer look on the platform and give it another try. And I did so. They say that abstract theoretical knowledge can’t compare with practical one, so I decided to make something small but more or less useful on WPF and therefore, get some practical knowledge of the technology.

I’ve set my choice on a little handy tool that will monitor and report the health of my network. For now the most quick and simple way to check the health is to open several Command Prompt windows and run a Ping command to various hosts in the network starting from my own router, then gate, VPN server, etc. and ending up with globally available hosts like google.com or similar. So you have to look at all those console windows, process and aggregate their logs and make a conclusion where the real problem is. As you might imagine, this way is neither convenient, nor informative, and finally, I’ve decided to create a better solution.

I’ve started with requirements. What are they?

The most important thing is to invent a codename. I’ve chosen a self-describing name — NetMonitor, why not?

UI

  • The main window shows a predefined read-only list of hosts and an average response time from Ping command.
  • Each host has a name and a valid internet address.
  • Two buttons start and stop the process of pinging.

Internals

  • In order the UI thread not to be frozen while waiting for Ping command response, each host pinging procedure must run in a separate thread.
  • Sending a Ping request once a second will be enough for monitoring tasks.
  • List of hosts for pinging should be configured from outside the application code, say, in app.config file or something. Personally, I don’t like xml configuration files, so i will try using ini file instead.

That will be enough, at least for the first version.

In the next posts I’ll write about the process of building the application.

No comments:

Post a Comment