A colleague of me is always pretty unsure what to set. So he always looks it up, so maybe one day he will find this post.. This is for you Fabian.

# Adding Themes to Xamarin.Forms App

I just want to make some short notes about themes in Xamarin.Forms Apps, since there are already a lot of tutorials available online, that go way deeper.

Themes
Themes are actually ResourceDictionaries. Each atomic type you use in your XAMLs and Styles, will be defined here. Types are f.e. Color, Double (for font sizes), etc.

<ResourceDictionary xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="ShoppingList.Themes.DarkTheme">
<Color x:Key="BackgroundColor">#333333</Color>
<Color x:Key="TextColor">#eeeeee</Color>
<Color x:Key="PlaceholderTextColor">#55ffffff</Color>
<Color x:Key="ControlBackground">#111111</Color>
<Color x:Key="ButtonBackgroundColor">#11ffffff</Color>
</ResourceDictionary>


Be sure to have a code behind file for your ResourceDictionary, that calls InitializeComponent(). Otherwise this will only work on UWP (without .NET Toolchain) and no other platforms.

Styles
In most cases the styles are not part of your themes, because using themes just makes you change the look of your pages and controls, not the styling of specific controls. Perhaps styles are using the resources, that you define in your theme. Be sure to use DynamicResource for linking to the key of the resource, otherwise you can not change themes during runtime. (Restart will be needed)

<ResourceDictionary xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="ShoppingList.Resources.Styles">
<Setter Property="BackgroundColor" Value="{DynamicResource BackgroundColor}"/>
<Setter Property="BarBackgroundColor" Value="{DynamicResource BackgroundColor}"/>
<Setter Property="BarTextColor" Value="{DynamicResource TextColor}"/>

</Style>
<Style TargetType="Label">
<Setter Property="TextColor" Value="{DynamicResource TextColor}" />
</Style>
<Style TargetType="Entry">
<Setter Property="BackgroundColor" Value="{DynamicResource ControlBackground}" />
<Setter Property="TextColor" Value="{DynamicResource TextColor}" />
<Setter Property="PlaceholderColor" Value="{DynamicResource PlaceholderTextColor}" />
</Style>
<Style TargetType="Button">
<Setter Property="TextColor" Value="{DynamicResource TextColor}" />
<Setter Property="BackgroundColor" Value="{DynamicResource ButtonBackgroundColor}" />

</Style>
</ResourceDictionary>


Changing the theme
Now you just need to add the following code to your App.xam.cs, then you can just call App.SetTheme(typeof(DarkTheme)) to change the theme during runtime.

Be sure to add all your style-ResourceDictionaries and a standard theme to your App.xaml in the Application.Resources-Section

internal static void SetTheme(Type themeType)
{
Preferences.Set("Theme", themeType.FullName);
var resDict = (ResourceDictionary)Activator.CreateInstance(themeType);
App.Current.Resources.MergedDictionaries.Add(resDict); // this line replaces all keys of the current dictionary with the value of the selected dictionary, only the keys that are present in the selected dictionary will be replaced
}


In your “OnInitialize” method of your App.xaml.cs you can put the following code, to load the saved theme on startup:

if (Preferences.ContainsKey("Theme"))
{
var themeTypeName = Preferences.Get("Theme",null);
var themeType = Type.GetType(themeTypeName);
if (themeType != null)
{
SetTheme(themeType);
}
}


# CSC : error CS1703: Multiple assemblies with equivalent identity have been imported (iOS)

I recently encountered a problem compiling my Xamarin.Forms iOS project. Everything worked well when testing the UWP App during development, but when I tried to test the iOS project, the compiler threw the following error:

CSC : error CS1703: Multiple assemblies with equivalent identity have been imported (iOS)'[..]\packages\system.reflection.emit\4.3.0\ref\netstandard1.1\System.Reflection.Emit.dll’ and ‘C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\Xamarin.iOS\v1.0\Facades\System.Reflection.Emit.dll’. Remove one of the duplicate references.

Checking those two files mentioned, you’ll find out, that those have two different versions (nuget cache: 4.3.0, VisualStudio: 4.0.0), also the path (and file size) states, that the file from the VisualStudio folder is only a facade.

The solution is quite simple, just add a package reference to your project-file excluding all assets:

<PackageReference Include="System.Reflection.Emit" Version="4.3.0">
<ExcludeAssets>all</ExcludeAssets>
</PackageReference>


.. just add it in an ItemGroup block with other package references and you solved that issue.

# read and write properties on dynamic objects in .NET/C#

Ok, the headline sounds a little bit funny, because first of all, dynamic objects have no properties. Also you can not use reflection on a dynamic type, because it’s dynamic. What I actually want to do, is to access values of a dynamic object by its name – but I don’t know the name of the property on compile time, but during execution.

I want to do something like that:

dynamic obj = GetDynamicObject();
string myPropertyValue = DynamicExtension.GetValue(obj, "MyProperty");
DynamicExtension.SetValue(obj, "MyProperty", "some cool value");


So how can we do this? Reflection is not possible, and not all dynamic types impement IDictionary like ExpandoObject.

But how can we achieve this? By looking at the disassembled code, of a dynamic class, and the way it is accessed, we can find out, how we can access it ourself…

dynamic dynObj = new TestClass
{
TestProperty = "Hello World",
TestInt = 20
};
var val = dynObj.TestProperty;
dynObj.TestProperty = "Hello C#";


Because I don’t want to flood this post, I just copied the essentials from the IL. Basically there are 2 parts:
1. create a Binder
2. create a CallSite to execute the getter/setter.

// the getter
var binder = Binder.GetMember(
CSharpBinderFlags.None,
"TestProperty",
typeof(object),
new CSharpArgumentInfo[] {

CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.NamedArgument, null)
});

var getter = CallSite<Func<CallSite,object,object>>.Create(binder);
var val = getter.Target(getter,  dynObj);

// the setter
var setterBinder = Binder.SetMember(
CSharpBinderFlags.None,
"TestProperty",
typeof(object),
new CSharpArgumentInfo[] {
CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null),
CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.UseCompileTimeType, null) });
// the IL actually uses string as value type, but we use object here, to be more flexible
var setter = CallSite<Func<CallSite,object,object,object>>.Create(setterBinder);
setter.Target(setter, dynObj, "Hello C#");



So now just wrap it up to our two functions:

    public static class DynamicHelper
{
public static object GetValue(object obj, string name)
{
var binder = Binder.GetMember(
CSharpBinderFlags.None,
name,
typeof(object),
new CSharpArgumentInfo[] {
CSharpArgumentInfo.Create(
CSharpArgumentInfoFlags.NamedArgument,
null)
});

var getter = CallSite<Func<CallSite,object,object>>.Create(binder);
return getter.Target(getter, obj);
}

public static void SetValue(object obj, string name, object value)
{
var setterBinder = Binder.SetMember(
CSharpBinderFlags.None,
name,
typeof(object),
new CSharpArgumentInfo[] {
CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null),
CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.UseCompileTimeType, null) });
// the IL actually uses string as value type, but we use object here, to be more dynamic
var setter = CallSite<Func<CallSite,object,object,object>>.Create(setterBinder);
setter.Target(setter, obj, value);
}
}


# C# Creating Types during runtime (.Net Core)

This is really fancy stuff, no one would probably never ever get along doing this. And I actually have no real straight forward “all day” use-case, I would ever recommend this for. But guess what, there is always an exception.

### So why am I doing this?

My situation is the following: On one hand I have a database (actually a Realm.io database). I want to copy that Realm into another Realm, but I didn’t find a tool, doing that for me. Because that is an object oriented database, we need the model definitions right when opening the database, but I wanted to create a tool, to copy data from one realm to another, without actually knowing the class models at all. So there is a pretty neat construct called “DynamicRealm”, one can just open those by passing a parameter while opening the Realm called “IsDynamic”. Then I don’t need to have the actual classes in my code. When I then open an existing Realm, it shows me all information about the schema, that is stored in the database (properties, attributes, etc.)…

So far, so good, .. I can read data. But my destination Realm is absolutely blank, no schema, no data. And in .NET there is no method implemented to create my own schema. There is only one thing I can do – adding Types while opening the Realm, and Realm will take care of creating the schema. So I need to impement type-creation from the schema during runtime.

### Creating the type during runtime

But before we create a type, we need to create an Assembly and Module, that type is going to be in. Be careful to use names, that aren’t already used. There are 3 Builders we use from the assembly System.Reflection.Emit : AssemblyBuilder, ModuleBuilder, TypeBuilder . In fact this part is pretty easy:

var parent = typeof(BaseClass); // the type of the baselcass for this type (can be null)
var name = "MyCoolTypeName"; // name of the new type

// 1. create assembly name
var assemblyName = new AssemblyName(\$"SomeAssemblyName{name}");
// 2. create the assembly builder
AssemblyBuilder assemblyBuilder = AssemblyBuilder.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);
// 3. that is needed to create a module builder
ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule("MainModule");
// 4. and finally our TypeBuilder (a public class)
TypeBuilder tb = moduleBuilder.DefineType(name,
TypeAttributes.Public |
TypeAttributes.Class
, parent);
Type type = tb.CreateType(); // of type Type, we can even create instances of that type

But when we want to create a real POCO we also need to add some properties to that type.
Add properties to the created Type (TypeBuilder)
This is not as easy, as it sounds like. We have to be aware, what is actually needed to create a property:
1. a backing field
2. a get method
3. a set method
Since we are in runtime mode, we need to create the method bodys in IL (which is the byte code used by .NET), so we cannot use plain C#.
(Be careful: all this can only run on systems with JIT compiler, so you cannot do that in UWP (with .Net Toolchain active) or iOS, Mono should be fine, but I didn’t test it yet)
So how to find out what IL to use? Just create a TestClass and produce some IL (I prefer using dotPeek from JetBrains):
.method public hidebysig specialname instance string
get_Text() cil managed
{
IL_0000: ldarg.0      // this
IL_0001: ldfld        string RealmCopy.TestClass::'_backingField'
IL_0006: ret

} // end of method TestClass::get_Text

.method public hidebysig specialname instance void
set_Text(
string 'value'
) cil managed
{
IL_0000: ldarg.0      // this
IL_0001: ldarg.1      // 'value'
IL_0002: stfld        string RealmCopy.TestClass::'_backingField'
IL_0007: ret

} // end of method TestClass::set_Text

After that, we can just write down the code for adding a property to the TypeBuilder:
public static void CreateProperty(TypeBuilder tb, string propertyName, Type propertyType)
{
if (propertyType == null) // when the propertytype is null, we assume, it's the Type itself (so we set it to the TypeBuilder)
{
propertyType = tb;
}

if (propertyType == typeof(IList&amp;amp;lt;&amp;amp;gt;)) // same thing here for a IList with no generic type parameter -&amp;amp;gt; we assume it's the type (we could probably do that for every generic type without type parameter)
{
propertyType = propertyType.MakeGenericType(tb);
}

FieldBuilder fieldBuilder = tb.DefineField("_" + propertyName, propertyType, FieldAttributes.Private); //creates the backing field
PropertyBuilder propertyBuilder = tb.DefineProperty(propertyName, PropertyAttributes.HasDefault, propertyType, null);

//get method
MethodBuilder getPropMthBldr = tb.DefineMethod(
"get_" + propertyName
,MethodAttributes.Public
| MethodAttributes.SpecialName
| MethodAttributes.HideBySig
, /*returnType*/ propertyType
, /*parameter types*/ Type.EmptyTypes); // see IL for the right MethodAttributes
ILGenerator getIl = getPropMthdBldr.GetILGenerator();
// create the code in the get method
getIl.Emit(OpCodes.Ldarg_0); //this
getIl.Emit(OpCodes.Ldfld, fieldBuilder); //backingfield
getIl.Emit(OpCodes.Ret);

// set method
MethodBuilder setPropMthdBldr =
tb.DefineMethod(
"set_" + propertyName,
MethodAttributes.Public
| MethodAttributes.SpecialName
| MethodAttributes.HideBySig
, /*returnType*/ null
, /*parameter types*/ new[] { propertyType }); // see IL for the right MethodAttributes

ILGenerator setIl = setPropMthdBldr.GetILGenerator();
// create the code in the set method
setIl.Emit(OpCodes.Ldarg_0); //this
setIl.Emit(OpCodes.Ldarg_1); // 'value'
setIl.Emit(OpCodes.Stfld, fieldBuilder); // backingfield

setIl.Emit(OpCodes.Nop);
setIl.Emit(OpCodes.Ret);

// add methods to the propertyBuilder
propertyBuilder.SetGetMethod(getPropMthdBldr);
propertyBuilder.SetSetMethod(setPropMthdBldr);
}



# Problem with ResourceDictionary in Xamarin Forms .Net Native

Last week a colleague had the idea, to split the Resources, that we have defined in App.xaml in several ResourceDictionaries. Since our App.xaml has grown to over 400 lines, we thought this would be a very good idea, and did it as always:

 <Application.Resources>
<ResourceDictionary xmlns:local="clr-namespace:TestResources">
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="/Resources/Buttons.xaml" />
<ResourceDictionary Source="/Resources/Labels.xaml" />
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Application.Resources>


Looks good, and when we were testing the App, it worked well. But as soon, as we wanted to ship the App to our customer, it totally crashed during start up. What was the difference? We always test Debug builds, but without .Net Native
Toolchain active, but for shipping, we made a Release build with .Net Native builds activated.

The following error occured:

Unhandled exception at 0x05B6B264 (Windows.UI.Xaml.dll) in TestResources.UWP.exe: 0xC000027B: Anwendungsinterne Ausnahme (parameters: 0x0B477CF8, 0x00000003).

In the output window we see a lot of error messages:

Unhandled exception at 0x05B4B264 (Windows.UI.Xaml.dll) in TestResources.UWP.exe: 0xC000027B: internal error(parameters: 0x0B44D9B0, 0x00000003).

Unhandled exception at 0x777AF989 (combase.dll) in TestResources.UWP.exe: 0xC0000602: Ein sofortiger Ausnahmefehler ist aufgetreten. Die Ausnahmehandler werden nicht aufgerufen, und der Prozess wird sofort beendet.

Unhandled exception at 0x77627ED3 (combase.dll) in TestResources.UWP.exe: 0xC0000005: Access violation reading location 0x00000008.

I am not quite sure, why this happens but the solution is quite simple:

• Add a code behind file (in our case Buttons.cs).
• In the constructor, call “InitializeComponent()”.
• Now we can include the ResourceDictionary directly in the App.xaml
• In our case the Buttons.xaml.cs looks like this:

   public partial class Buttons : ResourceDictionary
{
public Buttons()
{
InitializeComponent();
}
}


..and the App.xaml

<Application.Resources>
<ResourceDictionary xmlns:local="clr-namespace:TestResources">
<ResourceDictionary.MergedDictionaries>
<local:Buttons />
<!--<ResourceDictionary Source="/Resources/Buttons.xaml" />-->
<!--<ResourceDictionary Source="/Resources/Labels.xaml" />-->
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Application.Resources>


If you have a clue, why we need to go this way, just leave me a comment.

# Error 0xC000041D using GetCallingAssembly()

Reflection is very cool, the meta data system of .Net is pretty cool. You can create objects of a given class, without knowing it at compile time, by just looking it up and instantiating it using reflection. But how can I look up a type? Some times you only know the name of a type you want to create, without knowing the correct assembly. Let’s say we have an assembly, that holds a service implementation to create a object:

class MyService
{
object GetObject(string typeName)
{
}
}


The class we want to create, is in the assembly from where that function gets called. That is ok, but we don’t know that assembly at compile time, we can only find it out, when the function gets called. But how?

The regular solution would be, to use System.Reflection.Assembly.GetCallingAssembly(). But when we do this in .Net Nativ, we get an exception at runtime:

Unhandled exception at 0x78A7B264 (Windows.UI.Xaml.dll) in BlankApp3.UWP.exe: 0xC000027B

I think this is a bug within the .Net native compiler. But how can we find a workaround for that problem?

## 1. using a fully qualified type name

object GetObject(string typeName)
{
var type = Type.GetType(typeName);
return Activator.CreateInstance(type);
}


You can then actually use the complete name, including the namespace, when calling the function. (Something like: GetObject(“BlankApp3.Views.MainPage”)), so it’s not possible to lookup a type by name. But for our use case, it is enough.

## 2. lookup the assembly by name

object GetObject(string assemblyName, string typeName)
{
var assemblies = AppDomain.CurrentDomain.GetAssemblies();
var assembly = assemblies.FirstOrDefault(asm =>
asm.GetName().Name.Equals(assemblyName));
var type = assembly.GetTypes().FirstOrDefault(t =>
t.Name.Equals(typeName));
return Activator.CreateInstance(type);
}


This is the most flexible solution in our case (but it takes more time). You can even look through all loaded assemblies, and find types by name. Please be aware that there is another bug, preventing you from getting all types from all loaded assemblies (the solution can be found on stackoverflow).

# How to assign properties (fast) in C#?

Ok, the short answer to that question is easy, just assign it directly. That’s it, and this is the shortest blog post ever. But actually that’s not the point, I wanted to make. There are a bunch of methods to assign a class-property with a specific value, but how do they differ, when it comes to performance. Even though I can guess, that Reflection is probably very expensive, I have no real feeling to what degree. My measurements also came up with a surprise, I didn’t expect when I started this out.

## The setting

For me, it’s very interesting to investigate that on .NET Standard with C# in UWP, because we are currently developing an App with Xamarin.Forms. Please keep in mind, that the results may differ on .NET Core or other targets, but I think there will be no dramatic difference.

We will generate a TestClass with a property Sum, afterwards, we will read the value, add an iteration variable to it, and write it back to the property. Let’s do that more than 10000 times, so we get a good feeling for the performance.

## What possibilities we have?

Let’s do some brainstorming on what kind of methods we have to read and assign a value to a property.

1. Direct assignment
obj.Sum = obj.Sum + i

2. Reflection
var type = typeof(TestClass);
var sumProp = type.GetProperty("Sum");
var val = (int)sumProp.GetValue(obj);
sumProp.SetValue(obj, val + i);

3. Function
var func = (Action)((TestClass o, int n) => { o.Sum += n; });
func(obj, i);

4. Dynamic
dynamic objDyn = new TestClass();
objDyn.Sum = i + objDyn.Sum;


## Let’s start the test

First of all, we try to find out how long the first call takes. I assume, that the first access of a property takes longest. Afterwards it’s probably way faster. But enough talk about what might happen, get it on:

The measurements are in 10-7 s. As we can see, the first calls with dynamic objects is very slow. All other methods are really close to each other. Is this just because of the Debug mode? How about compiling the code with .Net native? Maybe we can distinguish the methods better in Release Mode.

This seems to be a better solution. We can see, that direct assignments and function calls are very close, and take no time at all. The function call is a little bit slower, just because of the overhead of the function. Reflection is slightly better in .Net nativ (app. 50%) and dynamic calls are 95% faster in native build, than they are in debug mode.

But when we think about a real App, the first call isn’t very interesting. Just assume we have an App to manage our Customers. A customer object has 20 properties (name, street, zip code, etc.), we have about 5000 customers, and a page that shows all customers in a table. Our Model needs to be mapped to a ViewModel to show it on the screen. That gives us 100.000 assignments. I think this is a very realistic scenario, we can investigate on. (we will skip the first assignment call in our measurements)

What we can see, is that (as expected) function-calls and direct assignments take nearly the same time. Dynamic assignments are surprisingly fast, and reflection is very slow. But what does “slow” mean in that context? Have a look at the times measured:

1. direct: 1,2 ms
2. function: 2,0 ms
3. dynamic: 7,6 ms
4. reflection: 74 ms

We got so far, let’s have a look at the same setting with .Net native builds:

Where is direct and function? Both measurements are under 1ms, so there is a real boost. But there is a big surprise – What happened to dynamic????

1. direct: 0,12 ms ( -90%)
2. function: 0,3 ms ( -85%)
3. reflection: 45 ms ( -39%)
4. dynamic: 249 ms ( +337%)

I’ll investigate that issue on one of my future posts, if you have any ideas, how this could happen, please feel free to add a comment.

## Conclusion

There is an eligible reason, why Microsoft introduced the dynamic objects. Dynamic objects are very common in scripting languages like PHP or JavaScript. When you use it to parse responses of a Rest-API or just want to read data from a Json in your own object structure. This is really neat because you don’t have to create an own class structure, that is only used as an intermediate layer.

I am very curious, so I also tried to use ExpandoObjects and in contrast to that a Dictionary<,>:

1. ExpandoObject: 800 ms
2. Dictionary<,>: 5 ms

So you should definitely try to use Dictionaries instead of any dynamic approach. It’s a little bit harder to code, but it seems to be worth it.

When it comes to reflection, you probably can not avoid it – it is also one of the big strength of C# and the .Net Framework, that makes it so flexible even when it’s still a strongly typed programming language. Although I will be careful in future developments, to find more conservative solutions, when possible.

Almost forgot… the winner is

direct assignment… I dare you knew that before 🙂

# Arduino Object-oriented

It has been more than a decade, that I switched over to programming in C# and even longer I am developing object-oriented code. But when it comes to Arduino, I can not count on C#. (Actually, there is an Arduino-like microcontroller, which can be programmed with C#. It is called Netduino) But we can still produce object-oriented code with Arduino.

Let’s first have a look at a simple Blink-App (from the Arduino tutorial).

// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin LED_BUILTIN as an output.
pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}


As you can see, there are two standard functions, that get called, when the code is deployed on the device. setup() when the device starts, and loop(), which is something like a while(true)-loop after the setup finished. The code does that, what it is meant to do, make a LED blink every second. But let’s assume we have a button, that shall turn the blinking on and off. My OOP-brain always keeps saying:

“There should be a LED-object and a Button-object”

I can imagine, that there are other solutions, but that was the first thing, that comes in mind when I think about it. So let’s draw something…

When we now come to the point to include those objects in the Standard setup-loop-pattern, we also need a loop and setup-function in each of the classes. These could be called from the main functions.

Here comes the code:

enum SwitchState
{
On,
Off
};
//---------- Light
class Light
{
SwitchState _currentState = Off;
byte _pin;

public:
Light(byte pin)
{
_pin = pin;
}
SwitchState GetCurrentState()
{
return _currentState;
}
// turns on the light
void TurnOn()
{
_currentState = On;
}

// turns off the light
void TurnOff()
{
_currentState = Off;
}

void Setup()
{
pinMode(_pin, OUTPUT);
}

void Loop()
{
if (_currentState == On)
{
digitalWrite(_pin, HIGH);
}
else
{
digitalWrite(_pin, LOW);
}
}
};
//---------- Button
class Button
{
SwitchState _currentState = Off;
byte _pin;

void OnSwitchChanged()
{
SwitchChangedEvent();
}

public:
void(* SwitchChangedEvent)();

Button(byte pin)
{
_pin = pin;
}

SwitchState GetCurrentState()
{
return _currentState;
}

void Setup()
{
pinMode(_pin, INPUT);
}

void Loop()
{
if (val == HIGH && _currentState == Off)
{
_currentState = On;
OnSwitchChanged();
}
else if (val == LOW && _currentState == On)
{
_currentState = Off;
OnSwitchChanged();
}
}
};

//-------------------------- MAIN
Light led1(1);
Button button1(2);

void InvertLight()
{
if (led1.GetCurrentState()==Off)
{
led1.TurnOn();
}
else
{
led1.TurnOff();
}
}

void setup() {
led1.Setup();
button1.Setup();
button1.SwitchChangedEvent = InvertLight;
}

void loop() {
led1.Loop();
button1.Loop();
}


From this starting point, you can do a lot of fancy stuff. First of all, you could implement a base class, to actually wrap up those functions, that tend to produce code doubles. Also you may not want to trigger (and write) the digital pins on every loop. You can simply introduce something like a timestamp, skipping the loop for an amount of time. Everything can be made in a base class, so there will be no need to implement it every time again.

# 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.