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
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.
Showing MahApps modals in a Prism WPF and MVVM friendly way (part 1).
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.
Showing MahApps modals in a Prism WPF and MVVM friendly way (part 2 - last).