Real singleton approach in WPF application
One of the most common problems in WPF is memory/processor time consumption. Yes, WPF is rather greedy framework. It become even greedier when using unmanaged resources, such as memory files or interop images. To take care on it, you can implement singleton pattern for the application and share only one unmanaged instance among different application resources. So today we’ll try to create one large in-memory dynamic bitmap and share it between different instances of WPF controls. Let’s start
First of all let’s create our single instance source. The pattern is straight forward. Create a class derived from INotifyPropertyChanged, create private constructor and static member returns the single instance of the class.
public class MySingleton : INotifyPropertyChanged {
#region Properties
public BitmapSource Source { get { return _source; } }
public static MySingleton Instance {
get {
if (_instance == default(MySingleton)) _instance = new MySingleton();
return _instance;
}
}
#endregion#region ctor
private MySingleton() { _init(); }
#endregion
Now we need to create this single instance of this class inside our XAML program. To do this, we have great extension x:Static
<Window.DataContext>
<x:StaticExtension Member="l:MySingleton.Instance" />
</Window.DataContext>
Now we need to find a way to do all dirty work inside MySingleton and keep classes using it as simple is possible. For this purpose we’ll register class handler to catch all GotFocus routed events, check the target of the event and rebind the only instance to new focused element. How to do this? Simple as 1-2-3
Create class handler
EventManager.RegisterClassHandler(typeof(FrameworkElement), FrameworkElement.GotFocusEvent, (RoutedEventHandler)_onAnotherItemFocused);
Check whether selected and focused item of the right type
private void _onAnotherItemFocused(object sender, RoutedEventArgs e) {
DependencyPropertyDescriptor.FromProperty(ListBoxItem.IsSelectedProperty, typeof(ListBoxItem)).AddValueChanged(sender, (s, ex) => {}
and reset binding
var item = s as ListBoxItem;
var img = item.Content as Image;
if (_current != null && _current.Target is Image && _current.Target != img) {
((Image)_current.Target).ClearValue(Image.SourceProperty);
}
if (img != null) {
_current = new WeakReference(img);
img.SetBinding(Image.SourceProperty, _binding);
}
We almost done. a bit grease to make the source bitmap shiny
var count = (uint)(_w * _h * 4);
var section = CreateFileMapping(new IntPtr(-1), IntPtr.Zero, 0×04, 0, count, null);
_map = MapViewOfFile(section, 0xF001F, 0, 0, count);
_source = Imaging.CreateBitmapSourceFromMemorySection(section, _w, _h, PixelFormats.Bgr32, (int)(_w * 4), 0) as InteropBitmap;
_binding = new Binding {
Mode = BindingMode.OneWay,
Source = _source
};
CompositionTarget.Rendering += (s, e) => { _invalidate(); };
private void _invalidate() {
var color = (uint)((uint)0xFF << 24) | (uint)(_pixel << 16) | (uint)(_pixel <<| (uint)_pixel;
_pixel++;unsafe {
uint* pBuffer = (uint*)_map;
int _pxs = (_w * _h);
for (var i = 0; i < _pxs; i++) {
pBuffer[i] = color;
}
}
_source.Invalidate();
OnPropertyChanged("Source");
}
And we done. The usage of this approach is very simple – there is no usage at all. All happens automagically inside MySingleton class, all you need is to set static data context and add images
<StackPanel>
<Button Click="_addAnother">Add another…</Button>
<ListBox Name="target" />
</StackPanel>
…
private void _addAnother(object sender, RoutedEventArgs e) {
var img = new Image { Width=200, Height=200, Margin=new Thickness(0,5,0,5) };
target.Items.Add(img);
this.Height += 200;
}
To summarize: in this article we learned how to use singletons as data sources for your XAML application, how to reuse it across WPF, how to connect to routed events externally and also how to handle dependency property changed from outside of the owner class. Have a nice day and be good people.
Source code for this article (21k) >>
To make it works press number of times on “Add another…” button and then start selecting images used as listbox items. Pay attention to the working set of the application. Due to the fact that only one instance is in use it is not growing.
You may also be interested with:
- Nifty time savers for WPF development
- Quick how to: Reduce number of colors programmatically
- INotifyPropertyChanged auto wiring or how to get rid of redundant code
- Quick Silverlight (and WPF) tip: How to write program without XAML
- Read and use FM radio (or any other USB HID device) from C#
August 24th, 2009 · Comments (4)
4 Responses to “Real singleton approach in WPF application”
Leave a Reply
Discover other tags
My tools
- .NET Framework Detector
- Duplicate images finder
- Exchange Security Policy for Windows Mobile Devices Fix
- Gas Price Windows Vista SideBar gadget
- Israel Traffic Information Windows Vista SideBar gadget
- Localization fix for SAP ES Explorer for Visual Studio
- LocTester
- RTL and LTR in Windows Live Writer
- Silverlight controls library
- Snipping tool integration plugin for WLW
- USB FM receiver library
- Vista Battery Saver
- WebCam control for WPF
- Windows Live SkyDrive attachment for Windows Live Writer
- Wireless Migrator
- WPF Virtual Keyboard




August 24th, 2009 at 3:13 pm
Be careful using singletons (they are an anti-pattern) they seem useful but they become painful later on when you want to do unit testing or use a different instance for some other reason. Use IoC (DI) instead
August 24th, 2009 at 4:18 pm
And why don’t call Freeze() method of Freezable objects, it will detached from dispatcher and you can use in every control you like and more faster, because MIL composition engine know about freezable objets.
Luis.
August 24th, 2009 at 10:56 pm
@MF sometimes you have no chance other than using Singletons
@Luis it’s because my singleton object is not freezable it’s only source for given dependency objects.
October 22nd, 2009 at 2:31 am
@MF You need to read the original “Design Patterns” book by the GoF (Gamma, etc).
Some of the _benefits_ of using the Singleton (as described in that classic book on patterns) is that you _can_ use different instances for different reasons.
In fact, using the Singleton pattern actually makes unit testing easy!
(In unit tests the accessor returns a mock or test version of the class, whilst the real code returns the real instance.)