Visual Studio for Mac tips & tricks

Switching from old good VS (for Windows) to a new cool VS for Mac can be painful. Original VS was released in 1997 (according to wikipedia) while VS for Mac was released only in 2016. Yes, it is based on XamarinStudio which is built on MonoDevelop but it still has a long way to go in order to be close to it’s ancient relative.

In this article we will take a look on VS for Mac “hidden gems” that can optimize and smooth your workflow. All you have to do is to open Mac’s VS Preferences and read this article on the side.

Environment

Font

One of the very basic yet very important settings is the Font. While there is nothing bad using the default font, FiraCode could beautify your code and improve it’s readability by replacing sequences of characters by a single ligature.

The project repository on github contains detailed information on how to install it in your system. It’s also great because this font can be used almost everywhere.

Continue reading “Visual Studio for Mac tips & tricks”

Advertisements

Using Native Facebook Login Button in Xamarin.Forms

This slideshow requires JavaScript.

Very often I hear questions like “Is there any Facebook SDK for Xamarin.Forms? Because there is one for Android Xamarin Native.”. This kind of questions can apply to different SDK that are compatible only with specific platforms and cannot be consumed directly in Xamarin.Forms. The answer to these questions usually is “If there is an available native Xamarin SDK it can be consumed in your Xamarin.Forms project. All you have to do is to create an abstraction like you would do with any other platform specific code.”.

As you might already understand, in this article we will create an abstraction over Xamarin.Facebook.Android and Xamarin.Facebook.iOS in order to display a native Facebook Login Button and handle the authentication related events in our Xamarin.Forms application.

Continue reading “Using Native Facebook Login Button in Xamarin.Forms”

Android emulators stopped working on macOS 10.13 (High Sierra)

Recently I updated my macOS to High Sierra however this broke my android emulators. Non of them started and logs showed something like:

Failed to open vm 3
Failed to create HAX VM
No accelerator found.
failed to initialize HAX: Invalid argument

As the logs states there is a problem with HAXM, and to be more specific a time for update has come. To solve the issue simply download the latest and greatest version of HAXM and restart your mac.

Installing Xamarin components

Xamarin components are easy to install, all you have to do is to download a zip, extract the content and to reference the dlls in your project. This would work if you download the component manually from components gallery. Same thing can be done using Visual Studio in a more robust way via ‘Components’ under the targeting platform projects. Either way, the component will be downloaded and installed only for a specific project.

Sometimes it might be useful to keep the component in cache, so it will be available globally. This is where the XAM file extension comes into play. Generally speaking, it is just an archive, you can change the file extension to zip and use it in a regular way, or vice versa change zip to xam.

Regardless of your OS you have to download xamarin-component.exe.
On Windows execute the next command:

xamain.component.exe install <component.xam>

On MacOS execute the next command with the same executable:

mono xamain.component.exe install <component.xam>

If the command executed successfully, you should see the installed component:

Screen Shot 2017-11-14 at 21.20.30

Please note the “Included in this project” and “Installed on this machine”. Components under the second section will be always there unless you will clean the cache. On MacOS the components will be installed under ‘~/Library/Caches/Xamarin’. Please let me know where the cached components are stored on Windows.

INotifyPropertyChange without boilerplate code in Xamarin.Forms

Implementing INotifyPropertyChange is pretty straightforward. Usually, you create a base ViewModel class which implements it and which usually contains RaisePropertyChanged method:

public abstract class BaseViewModel : INotifyPropertyChanged
{
    #region INotifyPropertyChanged
    public event PropertyChangedEventHandler PropertyChanged;

    protected void RaisePropertyChanged(
        [CallerMemberNamestring propertyName = )
    {
        PropertyChanged?.Invoke(thisnew PropertyChangedEventArgs(propertyName));
    }
    #endregion
}

Now you can extend the BaseViewModel and use it this way:

public class UserViewModel : BaseViewModel
{
    private string login;
    public string Login
    {
        get
        {
            return login;
        }
        set
        {
            if (login == value)
                return;
            login = value;
            RaisePropertyChanged();
        }
    }
    private string password;
    public string Password
    {
        get
        {
            return password;
        }
        set
        {
            if (password == value)
                return;
            password = value;
            RaisePropertyChanged();
        }
    }
}

For very small applications it can be a good enough approach, however, in bigger applications it turns into a lot of boring boilerplate code. Here is where NotifyPropertyChanged.Fody comes into play! With this nice package our code will turn into:


[ImplementPropertyChanged]
public abstract class BaseViewModel {}

public class UserViewModel : BaseViewModel
{
    public string Login { getset; }
    public string Password { getset; }
}

Easy as it is! I highly recommend to get familiar with the documentation as it contains a lot of useful information about more advanced flows. For example, if you need to RaisePropertyChange for dependent properties or to skip equality comparison.

Though about optimisation of work with XAML in Xamarin.Forms

What is great about Xamarin.Forms? XAML of course! Especially if you are familiar with it from WPF / Silverlight times. However, the experience with XAML in Xamarin.Forms is totally different. Unfortunately, you will not have such a great intellisense, by default you will have to discover typos in XAML at runtime, no visual editor (yet) and without preview. I have been using VS 2017 on Windows and VS For Mac on macOS, in both cases problems listed above exists.

There are a lot of threads on stackoverflow about these problems and I am repeating myself, again and again, so I decided to write a post about it. I don’t have a magic solution, just a few tricks and a though.

If you are already familiar with XAML and Xamarin.Forms and you don’t care that much about intellisence you can turn on XAML compilation to catch the typos at compile time.
You can enable it at the assembly level, by adding the next line of code to your AssemblyInfo.cs:

[assembly: XamlCompilation(XamlCompilationOptions.Compile);

Or turn XAML compilation at the class level, just the next line above class declaration:

[XamlCompilation (XamlCompilationOptions.Compile)];

More detailed information can be found here.

FYI: If you set the BindingContext inside XAML you may meet this bug.

Remember that all you do in XAML is compiled to code in the end. That means that if the IDE is not working that great with XAML for Xamarin.Forms at this time, you can write everything in plain C#!
Sounds weird, however, all the problems listed above will be solved – except preview. But I find it attractive enough to try. Defining your UI layout in code behind will not violate any of MVVM principles as far as it’s not going to include any business logic.

If you know any other tricks please share.
Have a nice week.

UIDatePicker Countdown mode bug and solution in Xamarin.Forms

Problem

Show hh:mm:ss picker on iOS using Xamarin.Forms.

Goal

Extend Picker view in order to achieve the next result:

Solution

First I tried to keep it simple: to give up on seconds and use UIDatePicker in UIDatePickeCountDownMode. So the end result will look like this:

I achieved it by extending the DatePicker and it’s DatePickerRenderer and changing the mode as described above. However, I discovered that ‘datePickerValueChanged’ is being called only on a second iteration with the values. The issue was successfully reproduced in Swift, so it’s not a Xamarin bug. The Swift version can be found here.
After spending some time understanding the issue described above, I found an example on StackOverflow, thanks to Mathieu who shared his solution. His example was based on XLabs, so I removed the dependency and shared it with the community.
The code can be found on GitHub.