XAML Developer Must Care About Your Registered Events

Memory leakage in applications are very common and in an effort to save time a developer does not care about it. There are various possibilities for memory leakage and one of them is the events registered in applications that a developer unknowingly forgets to handle.

So, what could be the cause of the problem and are there any proper solutions to tackle this issue? Let us discuss this topic today.

It's a common mistake by many developers, either they don't know about such possibilities in their applications or they just ignore/forget to take care of events. Let's begin with a realistic scenario.

Suppose you built an awesome application and tested it properly from your end, fixed various issues related to functionalities and UI issues. You also verified your app from a tester and received a green signal to deploy the app to the client's PC, mobile or any other targeted environment. You became happy deploying the app with nearly zero bugs.

Now after a few days the users report to you that they are facing many issues after installing your application. That will generally come to you as a thunderstorm and you will start asking the users to check the system configuration without first checking your app.

Later you will start tracing the app and discover that, the application is taking significantly more memory than expected and that is increasing in time because the user is opening some windows of your app, closing and reopening them multiple times. Sometimes the application is malfunctioning and retaining the previous values though the Window inside the app is closed.

The big boss is there and started shoutingatn you because he noticed some memory leaks in your application that you coded. There could be various possibilities to check it out for such memory leaks and one of them is event handling. You started searching for such possibilities in your code and noticed that you or your team member subscribed for various events and many of those events are registering multiple times in the lifetime of the screen. You also noticed that they were not removed after the completion of the actual operation. Thus it's keeping a strong reference to the object though the window has been closed or hidden.

Problem and Solution

As a developer we should take care of such event handling mechanisms; from the very beginning we start working on something by registering events. This is a common scenario in nerly all of the XAML technologies we work with (e.g. Silverlight, WPF, Windows Phone or Windows 8 RT applications etc.), when we register the event but don't care about deregistering it from memory. Sometimes it becomes even painful when multiple registration is done without removing the first instance of it. Thus your application starts misbehaving in some cases and increasing the memory use.

Since there are strong references to the memory locations present, the Garbage Collector does not go for collecting objects that are no longer used.

For example, the following code may produce memory leakage:

protected void OnUpdateClick(object sender, EventArgs args)

{

context.SubmitOperationCompleted += OnSubmitOperationCompleted;

context.Submit(accountDetails);

}

protected void OnSubmitOperationCompleted(object sender, SubmitCompletedEventArgs e)

{

MessageBox.Show("Account has been updated");

}

In the scenario above, since we are subscribing to the submit operation completed event on the click of an update button and before calling the actual submit method, this may occur multiple times. As we are not removing the reference from memory on successful completion, this may create memory leakage because of multiple event registration.

This could be easily resolved by removing the event from memory on completion of the completed event implementation and that would make the code less buggy. Here is a simple example of that:

protected void OnUpdateClick(object sender, EventArgs args)

{

context.SubmitOperationCompleted += OnSubmitOperationCompleted;

context.Submit(accountDetails);

}

protected void OnSubmitOperationCompleted(object sender, SubmitCompletedEventArgs e)

{

// first remove the event registration from memory

context.SubmitOperationCompleted -= OnSubmitOperationCompleted;

MessageBox.Show("Account has been updated");

}

That will free up the strong reference and if we do this for all of the event registration, there will be nearly no bugs in the code of strong unnecessary references in the code.

Yes, it's not 100% sure that it will completely remove the memory leakage from your application but will remove most of them. There could be other possibilities too, but let's discuss that sometime in another article.

1 Comment

Join the conversation! Your thoughts help the community grow.

Sam Hobbs13y ago
The debugger for unmanaged code will produce a report of memory leaks. It seems unlikely that managed code does not. I sure do not understand how memory leaks could be caused in the manner described here. Perhaps there is some other problem but I am skeptical that it is a memory leak.