How to success with DateTime in Xamarin application?

Photo by Kevin Ku on Unsplash

Date and time is a significant thing. It appears everywhere, from sorting a library of photos to managing a schedule and selecting flights. Not all developers take this into account when working on their applications.

Have you ever encountered problems when your application displays the wrong date for some users? Or when users cannot understand what 03.02.2020 means? Or messages in your chat application coming from the future? Or does the file filter display files from the Bronze Age? If you have answered “yes” at least once, this post may be useful for you.

In the following sections, I will describe the rules that I follow when dealing with date and time.

Use DateTime in UTC kind

The first rule: to deal with the UTC date on all layers of application, except for the View layer.

In most cases, API will send you a date in a universal format. Thus, there is no need to convert the date every time during the calculations.

Another reason: persisting DateTime in universal time will save us from errors if the local time for the user changed, as we will always have a universal date stored in the local storage.

Use TimeSpan class

Replacing int or long fields by TimeSpan is a good step forward to make your code safer and easier to read:

int vs TimeSpan in DateTime calculations

In the first case, the developer should always keep in mind the exact time unit delayInMinutes represents. What if someone decided to wait 10 hours instead? The first way: change the variable name, replace AddMinutes by AddDays, and update tests. The second one: assign delayInMinutes to 10 * 60. Doesn’t look easy, right? And, most importantly, the developer can make a mistake when changing this small constant.

Use friendly DateTime format

What is ‘friendly’ in this case? The short answer is: the date should look familiar to the user.

There are some key points when choosing the correct date and time format:

1. The user’s language and region.
2. The platform on which the user runs your application.

Implementation

The great news: popular platforms, like iOS and Android, provide a set of native methods to convert date time to the human-readable string.

Let’s focus on Xamarin.Android and Xamarin.iOS MVVM implementation using the MvvmCross framework.

The ViewModel should contain abstractions only. For instance: ICommand instead of Button, because Button is a platform-specific concept. The same applies to dates: use DateTime rather than string.

Assume we have the following ViewModel:

Core Part: mastering DateTime ViewModel

And there are views with a single text label for iOS and Android platforms:

iOS Platform: mastering DateTime VeiwController

Android Platform: mastering DateTime Activity

As you can see, the default binding applied and DateTime.ToString method used. Both platforms will display the same text: 03/02/2020 6:30:10 PM. Not so pretty, is it?

It is a time to create a custom property and use the native formatting mechanism:

iOS Platform: native DateTime formatting

Android Platform: native DateTime formatting

It is needed to update the binding description to make sure we are binding to the new property, not to the label text directly:

set.Bind(this).For(v => v.DateTime).To(vm => vm.DateTime);

Now the date looks different on both platforms:

• iOS: Feb 3, 2020 at 6:30:10 PM
• Android: February 3, 6:30 PM

Of course, there are a lot of options available when using the native formatting API. You could check the documentation:

• NSDateFormatter on iOS
• DateUtils on Android

Bonus: Value Converters

To make this conversion robust, developers could use ValueConverters while binding ViewModel to View. I created the MvvmCross Plugin with various DateTime Converters that uses native API mentioned above:

SByteDev/Net.MvvmCross.Plugins.DateTimeConverter

I hope you find these rules useful in your applications, and I wish you good luck with date formatting! Do not hesitate to share your thoughts and questions in the comments below.