Simplifying INotifyPropertyChanged further

I wrote this post a while back about how to simplify binding properties in Xamarin Forms. Playing around some more with reflection I managed to get rid of the requirement to have a private variable with each property. Instead I create it on the fly which just makes it even easier to create properties now. Let me explain how.

So based on my previous NotifyPropertyChanged.cs class I added a dictionary where I will store all the fields that is created at runtime.

The Get method will create the property based on the calling methods name the first time it’s called for and after that it will simply return the value:

The Set method will take the referred value and set it to the field with the name of the calling method:

When creating a binding property in a class that inherits from NotifyPropertyChanged we can now simply write like this:

Now that was a little bit easier than with the previous version of NotifyPropertyChanged now, was’nt it?<

Previous version:

Handling crashes in Xamarin applications

There is different ways to handle errors and crashes in applications. I have tried out many tools like for example, HockeyApp without ever becoming really satisfied with the results. Instead I decided to go custom and develop my own system. There is a few principles that I have been sticking to when developing it.

  1. The user should never experience(notice) a crash.
  2. Crashers/errors should never be kept under the radar.
  3. Crashes/errors needs to be caught as as possible.

Let’s dig deeper into these principles.

1. The user should never experience(notice) a crash.
What I mean by this is that even if crashes occur, which they will.. They should not break the application. The reason for this is that in far most cases the application will keep running fine even though a function crashes. Let’s take an analytics system for example. Let’s say that a crash happens while sending some user statistics to a service. Allowing this to crash the whole application and ruin the experience for the user wouldn’t much sense. How about an animation for a button? Nope.. There is things everywhere that might cause crashes without affecting the overall experience for the user.

2. Crashers/errors should never be kept under the radar.
The main argument against principle 1 I heard from other developers is that they are afraid that crashes will go unnoticed and cause symptomps that is hard to debug. This is where principle 2 comes into play. It’s crucial to never let an exception slip under the radar. I have noticed that some developers adds if-statements in many places to check for null and I would say that it’s is a bad practice. Let’s have a look at this example:

In this example we are asking a service for an order and if we receive the order we print information about it, but otherwise we print an error-page. What’s wrong about this example? The problem here is that we are trying to cover up for an underlaying issue; The question we should ask ourselves here is why we are receiving a null response. Probably something is wrong within the flow itself since we are trying to get an order that doesn’t exist and if we are masking this issue we will never get to ask ourself these questions and deal with the real issue. Instead we should catch the error, send the error-information to our online logging system and then, let the application continue as usual. I will show an example if this later on.

3. Crashes/errors needs to be caught as early as possible.
This principle goes along with principle 2. Again, let the error be triggered as early as possible instead of masking it. In best case scenario we would catch all errors during development and that is what I want to aid in the development of this system. That’s why I add a crucial step in my system which is to break the debugger if it’s attached when an error occurs. This will make any developer notice an error and easily find it since the debugger is attached with the callstack and all the parameters necesarry to resolve the issue.

Let’s look at the system now.
Basically I wrap all code in try/catch and in the catch method I simply send the information forward to my Crashhandler that will dig out all the information about the error using reflection and then send it to an online logging system (Loggly or Mixpanel for example).

The advantage of having our custom error-handling system like this is that we can add whatever information we want in the Log method. We can also use it for other things then catching errors. Maybe “warnings”?

Looking back at the previous example and adepting it to this system it would instead look something like this:

We could also use a hybrid-solution that would look something like this:

When loading XAML layouts in Xamarin.Forms causes an exception it usually gets masked by default. You might receive an error in the log at most but in a lot of cases the layout will simply not load but by wrapping InitializeComponent() in a try/catch statement you will instead receive a very nicely formatted error and a breaking debugger that will make your development so much smoother.

Inversing bool in XAML

I have seen a lot of these kinds of bindings in the Xamarin Forms community:

What I’m referring to is the IsNotPhotoVisible and IsPhotoVisible. It’s actually two different parameters in the view-model but the one is just a copy of the other but the inverse. Wouldn’t it be easier if there was a way to invert a property in the XAML-binding without having to create all these “NOT” properties? Well.. There is!

It’s called IValueConverter. I created this class named InverseConverter.cs:

Now we can simply call the converter from within the XAML like this:

Simplifying INotifyPropertyChanged

Honestly I’m not sure if I made this class or if someone else made it but it has been laying around for years and been a part of my toolbox so I thought I would share it 🙂

Normally a implementation of the INotifyPropertyChanged would look something like this:

I think it’s a risk and a bit of a hassle to have to enter a string for every parameter. Spelling misstakes will eventuelly occur. Instead I use a wrapper that automatically takes the name of the calling member.

The use of this wrapper will then look like this:

In XAML you will bind the property to ExampleParameter and voila, no hardcoded strings being passed around to the INotifyProperty interface anymore.

Xamarin.Forms Localizing with Xamarin Live Player

Switching between Xamarin Forms and Native Android Development back and forth I have noticed that there is one piece in the development toolbox that is extremly important but yet very lacking in Xamarin Forms.

That is; the ability to preview user interface layouts without having to compile, deploy and run the application every time.  The time spent iterating user interfaces without a well working layout previewer is a great waste of resources. Just imagine if a designer had to compile for 5 minutes between every change they made in Photoshop. Not very effecient, right?

Xamarin.Forms have made some attempts at solving this. They have the Xamarin.Forms Previewer which basically never works:

I don’t know if they stopped developing it because it seems to just be getting worse lately. Instead, it seems as if their focus shifted into a newer tool; Xamarin Live Player

So far I have been very happy with the Xamarin Live Player. It goes really quick and smooth to iterate on the user interface. However it’s still under development and doesnt support Custom Renderers or Embedded Resources (Limitations), the lately being a big blocker when following the recommended procedure for localizing using embedded RESX resource files.

I decided to modify their system a bit to be able to localize withour RESX files instead.

The first step is to get the language from the device of the user. This step remains the same as in the Xamarin Forms tutorial. For Android you need to implement localize.cs and for iOS, localize.cs and in the Portable project you need to implement the interface ILocalize.cs

Everything remains the same so far but now things will turn in a different direction; Instead of implementing resx files we will create one static file cs file for each language. In my example I will use English and Swedish.

To be able to call for these translations from XAML we need to create a Converter.

As you can see in the code I have hardcoded the mapping between culture name and translation class. This can be developed further to a more streamlined approach but I’ll keep it simple for now.

You will also notice that I have this parameter named “Text” in the top of the file. It’s there for a reason and it will become clear soon enough.

Now for the implementation in XAML.


I hope most of the code is self-explementary but what I want to point out here is the binding to Text. This is the parameter inside the LocalizeConverter and the reason we have to bind to it is because the xaml have to be bound to a parameter to be able to execute the converter. This is it. Now you should be able to localize your application and have it running the Live Previewer. This will work fine for setting the Title as well.

Since my device is set for English the result in the Live Previewer is in English: