Xamarin.Tips – MVVM Light Set Expressions Explained

I recently published a post about creating some Visual Studio code snippets for shorcutting the overhead of writing bindable properties and commands with MvvmLight. Xamarin.Tips – Visual Studio Code Templates/Snippets for MVVM Light

This post sparked some people who may or may not have used  Mvvm Light in the past to ask me about how it works underneath, and specifically the Set call made. For example:

private string _myText;

public string MyText
{
    get
    {
        return _myText;
    }
    set
    {
        // This is where the questions are.
        Set(() => MyText, ref _myText, value);
    }
}

I figured I would make another post to dissect this and explain what it is and how it is used!


First off, why are we doing this at all? What does this really do for us?

We use MvvmLight in order to create two-way or one-way bindings to our views whether that is in WPF, UWP, or Xamarin.Forms. The way these bindings are handled is by implementing INotifyPropertyChanged. When we implement INotifyPropertyChanged, we create a public event called PropertyChanged. PropertyChanged takes a custom EventArgs that includes the name of the property that was changed as a string. You would invoke that like this:

PropertyChanged?.Invoke(new PropertyChangedEventArgs("MyText"));

We can then have an event handler attached to this:

myViewModel.PropertyChanged += (sender, args) =>
{
    Console.WriteLine(args.PropertyName); // "MyText"
};

However, platforms such as WPF, UWP, and Xamarin give us the ability to use XAML to create these bindings like this (in Xamarin.Forms):

<Label Text="{Binding MyText}"/>

Setting bindings like this creates event handlers in the background if the BindingContext (or DataContext if you’re in UWP/WPF) implements INotifyPropertyChanged.

So now we can create auto-updating views with our bindings and calling PropertyChanged, but that’s a pain to do for every single property. That’s where libraries like MvvmLight come into play. They help handle a lot of the manual calls and ugly code. So now let’s look at what MvvmLight is really doing under the covers.

First, we need to look at the ViewModelBase class that MvvmLight ships and that contains the Set method we are talking about. ViewModelBase inherits from ObservableObject (another class MvvmLight), and ObservableObject is what is implementing INotifyPropertyChanged! We found it!

So how are ViewModelBase.Set and ObservableObject.Set making their way to calling PropertyChanged?

Let’s dissect the three parameters for the Set method used in the templates I created:

Set(() => MyText, ref _myText, value);
  1. The first is of type Expression<Func>. It is an expression that is returning the property that is calling it? This is where the fun stuff is really happening, so more on that later.
  2. The second is the underlying field that needs to be updated, passed in as a reference type rather than by value.
  3. The third is the new value that it is being set to.

The last two seem to make sense right away: what field are we updating, and what is the value we are setting it to? We need to pass the field in as a ref so that when we update it, it updates in the original model that passed it in rather than simply passing the value of the field into the method.

So what is that Expression?

The only thing left in order to call PropertyChanged is the name of the property being updated, so that must be what the property expression is for. Without decompiling the MvvmLight dlls and looking at the source code, we can infer how we might be able to pull the property name out of that Expression.

First, we need to get the Body of the Expression as a System.Linq.Expression.MemberExpression. The MemberExpression has a Member property which we can then pull property info from. We can cast that Member as a System.Reflection.PropertyInfo, and with that PropertyInfo, we can take the name of the property.

Expression<Func<string>> myTextExpression = () => MyText;
var body = myTextExpression.Body as MemberExpression;
var member = body.Member as PropertyInfo;
var finalPropertyName = member.Name; // we have it!

Then the final step is to finally invoke PropertyChanged with that property name.

I do also want to point out that although I use this particular Set method from MvvmLight, the ObservableObject and ViewModelBase do come with multiple overloads of Set that might work better for your preferred practices. For example, you can call Set without the property expression, and just pass the name of the property in directly. For example:

private string _myText;

public string MyText
{
    get
    {
        return _myText;
    }
    set
    {
        Set("MyText", ref _myText, value); 
    }
}

OR to be even more optimized, you can use nameof to get the name of the property without having to have string-literals floating around in your code:

private string _myText;

public string MyText
{
    get
    {
        return _myText;
    }
    set
    {
        Set(nameof(MyText), ref _myText, value); 
    }
}

Here are all the overloads available to use:

ViewModelBase.cs

protected bool Set<T>(Expression<Func<T>> propertyExpression, ref T field, T newValue, bool broadcast);
protected bool Set<T>(string propertyName, ref T field, T newValue = default(T), bool broadcast = false);
protected bool Set<T>(ref T field, T newValue = default(T), bool broadcast = false, [CallerMemberName] string propertyName = null);

ObservableObject.cs

// THIS IS THE ONE WE WERE USING
protected bool Set<T>(Expression<Func<T>> propertyExpression, ref T field, T newValue);
protected bool Set<T>(string propertyName, ref T field, T newValue);
protected bool Set<T>(ref T field, T newValue, [CallerMemberName] string propertyName = null);

If you happen to have any other questions about how this works, or about breaking down Expressions like we did, feel free to drop a comment on this post, or mention me on Twitter @Suave_Pirate.



And as always:



If you like what you see, don’t forget to follow me on twitter @Suave_Pirate, check out my GitHub, and subscribe to my blog to learn more mobile developer tips and tricks!

Interested in sponsoring your developer content? Message me on twitter @Suave_Pirate for details.

Xamarin.Tips – Restrict the Length of Your Entry Text

Here’s a quick one on how to restrict the number of characters a user can enter in an Entry. Basically, we are going to create a custom Behavior and then apply it to our Entry.

EntryLengthValidatorBehavior.cs

 /// <summary>
    /// Behavior that restricts the length of an entry
    /// </summary>
    public class EntryLengthValidatorBehavior : Behavior<Entry>
    {
        public int MaxLength { get; set; }

        protected override void OnAttachedTo(Entry bindable)
        {
            base.OnAttachedTo(bindable);
            bindable.TextChanged += OnEntryTextChanged;
        }

        protected override void OnDetachingFrom(Entry bindable)
        {
            base.OnDetachingFrom(bindable);
            bindable.TextChanged -= OnEntryTextChanged;
        }

        void OnEntryTextChanged(object sender, TextChangedEventArgs e)
        {
            var entry = (Entry)sender;

            if (entry.Text.Length > this.MaxLength)
            {
                string entryText = entry.Text;
                entry.TextChanged -= OnEntryTextChanged;
                entry.Text = e.OldTextValue;
                entry.TextChanged += OnEntryTextChanged;
            }
        }
    }

Now we can apply it in our Xaml:

<Entry x:Name="Pin1" TextColor="White">
    <Entry.Behaviors>
        <behaviors:EntryLengthValidatorBehavior MaxLength="4"/>
    </Entry.Behaviors>
</Entry>

If you like what you see, don’t forget to follow me on twitter @Suave_Pirate, check out my GitHub, and subscribe to my blog to learn more mobile developer tips and tricks!

Xamarin.Tips – Visual Studio Code Templates/Snippets for MVVM Light

This is a short set of freebies. If you use MVVM Light in your Xamarin or Windows projects, this will save you loads of time. I’ve created a few short cuts for Visual Studio to generate code templates for your ViewModels!

If you aren’t using things like prop or ctor, then you should be! Why write out all that code when you don’t have to!

Take these snippets, and install them into your VS instance. There is documentation here on how to do this: https://msdn.microsoft.com/en-us/library/ms165394.aspx.

For those of you who are not aware of the pain of creating large ViewModel classes, this is what an ordinary property might look like:

private string _myText;
public string MyText
{
    get
    {
        return _myText;
    {
    set
    {
        Set(() => MyText, ref _myText, value);
    }
}

And then setting up a Command:

private ICommand _myCommand;
public ICommand MyCommand
{
    get
    {
        return _myCommand ?? (_myCommand = new RelayCommand(() => { ... }));
    }
}

So let’s look at some templates. I have a repo up here where I’ve added the two we will talk about here, but I’d love to see more in there!

First, the bindable property:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
	<CodeSnippet Format="1.0.0">
		<Header>
			<Title>propb</Title>
			<Shortcut>propb</Shortcut>
			<Description>Code snippet for an automatically implemented bindable property
Language Version: C# 3.0 or higher</Description>
			<Author>Microsoft Corporation</Author>
			<SnippetTypes>
				<SnippetType>Expansion</SnippetType>
			</SnippetTypes>
		</Header>
		<Snippet>
			<Declarations>
				<Literal>
					<ID>type</ID>
					<ToolTip>Property type</ToolTip>
					<Default>int</Default>
				</Literal>
				<Literal>
					<ID>property</ID>
					<ToolTip>Property name</ToolTip>
					<Default>MyProperty</Default>
				</Literal>
				<Literal>
					<ID>field</ID>
					<ToolTip>Field name</ToolTip>
					<Default>_myField</Default>
				</Literal>
			</Declarations>
			<Code Language="csharp"><![CDATA[private $type$ $field$;

	public $type$ $property$
	{
		get 
		{ 
			return $field$;
		}
		set 
		{ 
			Set(() => $property$, ref $field$, value);
		}
	}
	$end$]]>
			</Code>
		</Snippet>
	</CodeSnippet>
</CodeSnippets>

So now we can type propb > Tab > Tab and get our template going!

And then of course for our RelayCommand:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
	<CodeSnippet Format="1.0.0">
		<Header>
			<Title>rcmd</Title>
			<Shortcut>rcmd</Shortcut>
			<Description>Code snippet for an automatically implemented relay command
Language Version: C# 3.0 or higher</Description>
			<Author>Microsoft Corporation</Author>
			<SnippetTypes>
				<SnippetType>Expansion</SnippetType>
			</SnippetTypes>
		</Header>
		<Snippet>
			<Declarations>
				<Literal>
					<ID>property</ID>
					<ToolTip>Property name</ToolTip>
					<Default>MyProperty</Default>
				</Literal>
				<Literal>
					<ID>field</ID>
					<ToolTip>Field name</ToolTip>
					<Default>_myField</Default>
				</Literal>
			</Declarations>
			<Code Language="csharp"><![CDATA[private ICommand $field$;

	public ICommand $property$
	{
		get 
		{ 
			return $field$ ??
				($field$ = new RelayCommand(() => { $end$ }));
		}
	}
	]]>
			</Code>
		</Snippet>
	</CodeSnippet>
</CodeSnippets>

The shortcut for this is rcmd > Tab > Tab, and we have our neat little RelayCommand that even brings our cursor back to inside the RelayCommand where we can continue to write out our logic.

Now go out there and write less code faster!

If you like what you see, don’t forget to follow me on twitter @Suave_Pirate, check out my GitHub, and subscribe to my blog to learn more mobile developer tips and tricks!

Xamarin.University Guest Lecture – Xamarin.Flux

Excited to announce I’ll be instructing a lecture on Xamarin University on February 23rd, 2017!

Be sure to come check it out: https://university.xamarin.com/guestlectures/architecting-your-app-with-xamarin-facebook-flux 

The topic is on using the Flux design pattern to build Xamarin applications as seen in my video and GitHub.

Onionizing Xamarin Part 6

For those who just want code: https://github.com/SuavePirate/Xamarin.Onion 

Don’t forget:

  1. Part 1 on the general project structure: Onionizing Xamarin Part 1
  2. Part 2 on our Domain and Application layers: Onionizing Xamarin Part 2
  3. Part 3 on our Infrastructure layer: Onionizing Xamarin Part 3
  4. Part 4 on our Client layer and Xamarin.Forms implementation: Onionizing Xamarin Part 4
  5. Part 5 on creating custom Platform specific logic: Onionizing Xamarin Part 5

A strong and scale-able architecture is important in applications, especially in Mobile Apps. APIs and SDKs are constantly changing, new technology is constantly released, and team sizes are always changing. A solid Onion Architecture can save a development team a lot of time by making it simple to change service implementations, restrict access to certain areas, making logic flow easy to follow, and making testing isolated blocks of code easier.

Some of the important topics this will cover:

  • Separation of Concerns
  • Inversion of Control
  • Dependency Injection
  • Model-View-ViewModel
  • Testability
  • Why all these things are important

Part 6

In this section, we will talk briefly about building useful tests for our solution, and why the Onion pattern makes it easy to break tests out into individual layers.

In this example, we will add a test project whose purpose it to just test the Business layer within our Infrastructure.

Tests.Business

Let’s start with by adding a nUnit project to our solution, or by adding the nuget package to a class library. Xamarin has great documentation on this: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/installing-nunit-using-nuget/

In our project, we also want to install MvvmLight, just like in our Client and Platform layers. We will also need to add references to our Domain.Models, Domain.Interfaces, Application.Models, Application.Interfaces, and Infrastructure.Business projects.

In order to test our Infrastructure.Business project, we will need to create mock versions of our Data project. In our test project, we can create Repository implementations with mock data for each set that we need. For example:

MockGenericRepository.cs

public class MockGenericRepository : IGenericRepository
{
    private List _data;
    public MockGenericRepository()
    {
        _data = new List();
    }

    public void Add(T entity)
    {
        _data.Add(entity);
    }

    public void AddRange(IEnumerable entities)
    {
        _data.AddRange(entities);
    }

    public Task CommitAsync()
    {
        return Task.FromResult(false); // we don't need to explicitly save changes
    }

    public Task FindAsync(Func<T, bool> predicate)
    {
        var entity =_data.Where(predicate).FirstOrDefault();
        return Task.FromResult(entity);
    }

    public Task<IEnumerable> GetAsync(Func<T, bool> predicate)
    {
        var entities =_data?.Where(predicate);
        return Task.FromResult(entities);
    }

    public void Remove(T entity)
    {
        _data.Remove(entity);
    }
}

and MockUserRepository.cs

public class MockUserRepository : MockGenericRepository, IUserRepository
{
    public MockUserRepository()
    : base()
    {
    }
}

Now that we have some mock implementations, we can set up our tests against our Business logic.

UserBusinessTests.cs

public class UserBusinessTest
{
    private IUserService _userService;

    [SetUp]
    public void StartUpIoC ()
    {
        ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
        SimpleIoC.Default.Register<IUserService, UserService>();
        SimpleIoC.Default.Register<IUserRepository, MockUserRepository>();

        _userService = SimpleIoC.Default.GetInstance();
    }

    [Test ()]
    public async void AddUserTest()
    {
        var result = await _userService.CreateUserAsync(new NewUser
            {
                Email = "test@test.com",
                FullName = "Testy McTest"
            });
        Assert.IsNotNull(result.Data);
    }
}

Now we can test against any of the business logic in our application with a mock layer. The same practice can be applied to test any other layer in the solution as well. The data layer can be tested by mocking the business layer, and so on.

Conclusion

Looking back at all of the components of our Onion Architecture, one might think, “Wow, that’s a lot of code to do a simple task”. It’s important to remember that this architecture is not for every project. It’s focus is on scalability and testability. If your project has the potential to grow into something quite complicated, with many developers involved, this type of solution might work best for you. However, if you’re working on something quick to get out the door, maybe getting right to the point is easier and best for you.

The best parts about the Onion Architecture are its abilities to make drastic changes to tools or services used, without having to rewrite anything but that components implementation as well as making it easy to test individual layers without affecting the others or using real data. It also allows for closer monitoring and management of the codebase; keeping people from making calls directly from one layer to another. The only thing you have to emphasize is, “Are you adding a reference to another project to get something done? If so, you might be doing it wrong”.

Onionizing Xamarin Part 5

For those who just want code: https://github.com/SuavePirate/Xamarin.Onion 

Don’t forget:

  1. Part 1 on the general project structure: Onionizing Xamarin Part 1
  2. Part 2 on our Domain and Application layers: Onionizing Xamarin Part 2
  3. Part 3 on our Infrastructure layer: Onionizing Xamarin Part 3
  4. Part 4 on our Client layer and Xamarin.Forms implementation: Onionizing Xamarin Part 4

A strong and scale-able architecture is important in applications, especially in Mobile Apps. APIs and SDKs are constantly changing, new technology is constantly released, and team sizes are always changing. A solid Onion Architecture can save a development team a lot of time by making it simple to change service implementations, restrict access to certain areas, making logic flow easy to follow, and making testing isolated blocks of code easier.

Some of the important topics this will cover:

  • Separation of Concerns
  • Inversion of Control
  • Dependency Injection
  • Model-View-ViewModel
  • Testability
  • Why all these things are important

Part 5

In this section, we will look at how to expand our Inversion of Control container with platform specific code. Specifically, we will implement some pieces of the HockeyApp SDK so that we can make calls to it from our Client or Infrastructure layers.

Our example will focus on just Android, but the same principles can be applied to any of the unique platform projects.

Platforms.Android

First thing we need to do is make sure we also install the MvvmLight nuget package in your Android project, as well as the HockeyApp Xamarin package.

From here, we can go back to our Application.Interface layer and create a new service:

ICrashAnalyticsService.cs

public interface ICrashAnalyticsService
{
    void Initialize();
    void GetFeedback();
}

Setting it up generic like this allows us to switch providers from HockeyApp to some other service should that be a need in the future.

Back in our Android project, let’s implement the ICrashAnalyticsServicewith our HockeyApp logic.

HockeyAppService.cs

public class HockeyAppService : ICrashAnalyticsService
{
    private const string HOCKEYAPP_KEY = "YOUR_HOCKEYAPP_KEY";
    private readonly Android.App.Application _androidApp;
    private readonly Activity _context;
    public HockeyAppService(Activity context, Android.App.Application androidApp)
    {
        _context = context;
        _androidApp = androidApp;
    }
    public void GetFeedback()
    {
        FeedbackManager.ShowFeedbackActivity(_context.ApplicationContext);
    }

    public void Initialize()
    {
        CrashManager.Register(_context, HOCKEYAPP_KEY);
        MetricsManager.Register(_androidApp, HOCKEYAPP_KEY);
        UpdateManager.Register(_context, HOCKEYAPP_KEY);
        FeedbackManager.Register(_context, HOCKEYAPP_KEY);
    }
}

Now we can create an IoCConfig class specific to our Android project. Because SimpleIoC uses a singleton for its container, we can register classes in our platform specific classes before our registrations in the Client layer.

AndroidIoCConfig.cs

public class AndroidIoCConfig
{
    public void RegisterAndroidServices(Android.App.Application application, Activity activity)
    {
        var hockeyService = new HockeyAppService(activity, application);
        hockeyService.Initialize();
        SimpleIoc.Default.Register<ICrashAnalyticsService>(() => hockeyService);
    }
}

Don’t forget to add a reference to the Application.Interfaces project in your platform project.

Lastly, let’s update our MainActivity to initialize our AndroidIoCConfig before we start up the  Xamarin.Forms app:

MainActivity.cs

public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity
{
    protected override void OnCreate(Bundle bundle)
    {
        TabLayoutResource = Resource.Layout.Tabbar;
        ToolbarResource = Resource.Layout.Toolbar;

        base.OnCreate(bundle);
        global::Xamarin.Forms.Forms.Init(this, bundle);
        InitializeIoC();
        LoadApplication(new App());
    }

    private void InitializeIoC()
    {
        var container = new AndroidIoCConfig();
        container.RegisterAndroidServices(Application, this);
    }
}

Now we can make calls to our ICrashAnalyticsService from the Client layer, and use the Android specific logic. For example, we can pass the ICrashAnalyticsService into the constructor of a ViewModel, and call the GetFeedback() method to get access to the HockeyApp Feedback view.

ExampleViewModel.cs

public class ExampleViewModel : BasePageViewModel
{
    private readonly ICrashAnalyticsService _crashAnalyticsService;
    private ICommand _feedbackCommand;

    public ICommand FeedbackCommand
    {
        get
        {
            return _feedbackCommand ??
                (_feedbackCommand = new RelayCommand(() =>
                {
                    _crashAnalyticsService.GetFeedback();
                }));
        }
    }
}

It’s all that simple! The same pattern can be applied to anything that needs to be platform specific.

What’s Next

In the next and final segment, we will look at building mock implementation of our Infrastructure layer and using them to test layers individually in Unit tests.

Next: Onionizing Xamarin Part 6