Introduction
I absolutely love the idea of Smart Clients. The more exposure I have to them the more I see the vast potential they offer. In my first article on Smart Clients, I had a personal goal to tackle the main tenants of Smart Client design. There are two aspects of Smart Client design I touched on in that article, but wanted to go into greater depth. The topics in question are the purpose of a rich (WinForms) UI and the role of local resources.
Like the previous article, all the source for this project is based on the 2.0 framework.
Summary
Every time you go to a FedEx or UPS store, they have 5 or 6 clocks on the wall showing the time in major cities around the world. I thought it would be fun to put together a Smart Client using the same notion of showing the current time in multiple time zones. This Smart Client uses a web service provided by www.worldtime-clock.com. Their web service has two methods: one to get a list of time zones, and one to return the current time in a given time zone. This remote data source is synchronized with US Naval atomic clocks and gives the user the ability to query any time zone, not just the 24 conventional areas.
Rich UI
The advantage of using a WinForms UI for Smart Client development is that you have all the power of tools like GDI+ which add flare to your UI. In the case of this application I created two custom controls to create a rich environment. The first control is a custom panel that displays a caption with a gradient background (similar to the FotoVision control). There is no inherent advantage to using a custom control, but it makes the UI much more appealing. And yes, aesthetics and usability are a concern with Smart Clients.
The second control is a Clock control that�s fully customizable. The clock allows for all of its display properties to be configured at design or run time. For this application I�ve set up a small �design environment� for a user to create and customize a clock to their liking. The clock is tied to the time in a given time zone, displayed on the main form, and then it just keeps ticking. Of course, since the focus is on a rich UI, the clock has tooltip information, context menus, etc� that set it apart form a web-based alternative.
Local Resources
The other advantage of Smart Clients is their ability to use local resources (unlike browser-based applications). The first local resource I�m using is simply the local system time. The problem with calling a web service to get time in a time zone is that you have no idea how long the request will take. A slow network connection or heavy traffic on the site may cause latency on the return from the web service.
For example, let�s say you�re on the East coast, it�s 4:00:00 pm, and you�re calling the web service to get the time in Arizona. (You�re doing this because Arizona doesn�t use daylight savings time and you can�t remember if they�re 1 or 2 hours ahead.) If there is any lag in the web service, say 15 seconds, you still get back a value of 5:00:00. The problem is that now your local time is 4:00:15. That means the time returned by the web service is off by 15 seconds. It wouldn�t make sense if each clock you add showed a different value for the seconds.
I�m using the local system time to fix any latency problems by adjusting the returned time to reflect the current seconds on the local machine. It�s not complex by any means, but it�s a great example of why a Smart Client shouldn�t rely purely on remote resources.
public DateTime GetCurrentTime(string timeZone)
{
WorldTime.WebClock worldTime = new WorldTime.WebClock();
worldTime.GetTime(timeZone);
DateTime adjustedTime = new DateTime(zoneTime.Year, zoneTime.Month,
zoneTime.Day, zoneTime.Hour, zoneTime.Minute,
DateTime.Now.Second);
return adjustedTime;
}
User Settings
The next local resource is user settings. The app allows a user to add an unlimited number of clocks. When the application is exiting, a custom Settings object persists the clock layout and time zone settings. Those settings are loaded the next time the app starts and the user�s clocks are recreated. Because the difference between the local time and the clock�s time zone is persisted, it�s not necessary to call the web service again to check the times. (Is the advantage of using local resources starting to make sense? The point here is not additional calls out to the internet.)
The settings are stored using the new ApplicationSettingsBase
class. I created a custom class to hold my settings, a generic List<>
that contains the custom Settings class.
public class ClockSetting
{
private int _someValue;public ClockSetting() { }
public int SomeValue
{
get{ return _someValue; }
set{ _someValue = value; }
}
}
public class TimePieceSettings : ApplicationSettingsBase
{
[UserScopedSetting()]
public List<ClockSetting> ClockSettings
{
get { return (List<ClockSetting>)this["ClockSettings"]; }
set { this["ClockSettings"] = (List<ClockSetting>)value; }
}
}
_settings = new TimePieceSettings();
foreach (ClockSetting setting in _settings.ClockSettings)
{
AddClock(setting);
}
foreach(Clock clock in _layoutPanel.Controls)
{
ClockSetting instance = CreateSetting(clock);
_settings.ClockSettings.Add(instance);
}
_settings.Save();
There�s almost nothing to it. Less than 5 lines of code for loading or saving custom user settings locally.
Well, there you have it. Another Smart Client example to experiment with. I hope I�ve shed some light on the question of why local resources are an important part of Smart Client development, and what advantages rich UIs have.
Enjoy!