Do I really need to unsubscribe every event?

I’ve seen a lot of source code in my life. Some really good code, that I loved to read and understand. My wife loves to read good books, I love to read good source code. 🙂

But sometimes, you read lines of code and think: Why??? Why, is someone doing this??? I remember one code snipped, I’ve seen a couple of months ago. I think the developer was afraid of memory leaks, maybe he read an article about events causing memory leaks, when they are not detached.

To summon up the code, it was as simple as that:

A ViewModel_A published an event and ViewModel_B subscribed to it. The guy writing it (I think he tried to “optimize” it..) made both ViewModels IDisposable and ViewModel_B unsubscribed that event. It wasn’t quite clear who actually disposes the objects of ViewModel_B, but that’s another story.

But, do we really have to unsubscribe each event, we ever hook on? Short answer NO! It actually depends on your use case and the lifetime of each object. ViewModels usually have a short lifetime (as long as you are visiting the page), therefore you don’t normally have to destroy the subscription. (In regular settings, you actually don’t need events within ViewModels, but I will not say never)

So let’s have a look at our sample, with all available connections. We have a View, with ViewModel_A as the BindingContext. The View_A has a ListView with items, each item has ViewModel_B as the BindingContext. And each ViewModel subscribes to the UpdateEvent. (Ok, I made this one up, to be more logical, even though I would probably solve such a setting in a different way).

The Garbage Collectors looks through the references, and as long as View_A is somehow in a NavigationStack, or viewed on the screen, everything stays in memory. Let’s say our View_A gets disposed because the user closes the page (or whatever). Now we have lost all connections, and only the event will keep both ViewModels connected. But all of those ViewModels have no connection to a View anymore, so they are both dead, and the Garbage Collector will sooner or later clean them up.

But are there cases, when I need to tidy up on events?
Yes, definitely, there are some cases. You just have to keep one thing in mind:

The publisher keeps the subscriber alive. Not vice versa.

Let’s say we have a service, which is implemented as a singleton (or instantiated as such in an IOC container). So the object is alive over the whole app lifecycle. When this service publishes an event, and a ViewModel subscribes it, the ViewModel will never get destructed (perhaps sometime, when the app terminates). But beware, that just implementing an interface like IDisposable will not solve your problem .. you also need to use it and think of when you want to dispose of your object. Prism has a nice variant for PageViewModels; indestructible. When you use Prism, just have a look at it, it’ll help you with that decision.

using enums with Realm

Realm is a very sweet object-oriented database engine for various languages. Since I am a .Net developer, I’ll stick to the features and problems we have using it within Xamarin Apps.

Recently we encountered a problem, using enums within a RealmObject. The most challenging thing in using Realm is, the constraint that comes with the Realm Models, they can not inherit each other, and Properties may only be a hand full of types or other RealmObjects (see: Realm: Supported Types). For a complete reference to Realm, feel free to stick to the .Net Tutorial on realm.io, it’s pretty neat.

So, as you can imagine from the headline, there is no out-of-the-box support for enums, but it’s pretty easy to achieve a proper solution.

Let’s assume we have Model with some enums:

public class Transaction : RealmObject
{
[PrimaryKey]
public int TransactionId { get; set; }
// this will not compile
public TransactionState State { get; set; }
public string Subject { get; set; }
public double Amount { get; set; }
}
public enum TransactionState
{
Open,
Comitted,
InTransaction,
Aborted,
Failed
}

The problem with this code snippet is, that enums are not supported in Realm, so the compiler (actually Fody) will give us an error, stating it is not a supported type:

Error Fody/Realm: Transaction.State is an ‘AsyncViewModel.Models.TransactionState‘ which is not yet supported. Models\Transaction.cs 12

How to solve this problem? Enums are always backed by another type, usually, it is an int (one can specify other types, but this is normally not the case). How about saving the int to Realm? But we want to keep the actual enum within the model, so we use a pseudo property (since Realm can only save auto-properties, no fields).

public TransactionState State
{
get { return (TransactionState)StateId; }
set { StateId = (int)value; }
}
public int StateId { get; set; }

So that’s it. We could also add an [Ignored] Attribute to the State property, but Fody is automatically ignoring non-auto properties.

About me

This is my awesome first blog post… Now that I got everything set up, I don’t really know, what to write. Let’s talk about me – I am Tom, born in the early ’80s and a Software Developer and father of three beautiful kids. I am writing Software as long as I can think of and got in touch with all varieties of languages from QBasic over Pascal to C++ and other very kinky languages like RGH Profan. Right now I am stuck with C#.

I used to write a German blog, that I started to just collect some code snippets for myself, that I don’t always want to search through the Internet. But I got very constructive feedback, so I figured out, I can really inspire and help people with my coding ideas – even though they are really confusing sometimes.