WPF might eat your entire memory... by design

Tags: prism, wpf, mahapps, memory, memory leaks, binding

Yes, you read it right. But the good news is: it probably won't. So the title is a little clickbait.

I'm developing some new CNC control applications and decided to go with the WPF to make them more appealing and to ease myself with UI and logic development.

Generally, I don't regret it that much. Partially thanks to a great MahApps library that makes developer's life a little bit easier and more fun.

But there are some caveats in the WPF itself.

For one, I was wondering if I should ALWAYS use INofityPropertyChanged and INotifyCollectionChanged (namely ObservableCollection<..>) or not, because I don't like them anywhere else than in ViewModels (BTW I'm using Prism and I suggest you do the same for any non-micro WPF app). In some older project I used those interfaces more extensively, but in the end, I think it wasn't a good idea and I didn't like it.

So the bottom line was: I didn't want to use those interfaces, but I didn't want to have any troubles either.

WPF Binding memory leaks... or does it?

There are a lot of information on the Internet regarding this topic and I guess it all originated from this KB938416

But there is a lot of misconception too, I think.

This KB talks about a very specific situation, where the child element (that doesn't implement INofityPropertyChanged) refers to a target element in XAML (most likely a parent) and you basically delete the parent element.

Nothing more, but reading some posts you might get the impression, that when you don't use INofityPropertyChanged then you'll always get the memory leak.

Nevertheless, I decided to check if just not using INofityPropertyChanged in an app that closely resembles a real-life app (not some crappy sample just to prove the point) is enough to get the leaks.

Spoiler alert: it's not

When your ViewModel implements INofityPropertyChanged (like it probably will when using some MVVM framework) and when you're not doing something very uncommon like referencing a target XAML element (or parent) and then deleting the parent - then you're fine and the memory is not leaking even when you're using a regular array of POCO objects and you set this array as ListBox.ItemsSource many times. The memory is not leaking so you don't have to implement interfaces just to satisfy WPF.

I've prepared a sample application that illustrates this situation with POCOs and ListBox.ItemsSource (quite common I guess) and I'll show it to you in the next post.

Read also

Prism WPF + MahApps modal window the MVVM way - part 1

Showing MahApps modals in a Prism WPF and MVVM friendly way (part 1).

Android app will eat its entire memory... by design

If you're developing for Android, I'm sure you already know that it's not as easy as it looks or people say. Well, OK, maybe it is EASY, but at the same time, it can be extremely FRUSTRATING.

Prism WPF + MahApps modal window the MVVM way - part 2

Showing MahApps modals in a Prism WPF and MVVM friendly way (part 2 - last).

Comments