• INotifyPropertyChanged, The .NET 4.6 Way posted on 12 Sep 2015

    This article is part of a series:

    1. INotifyPropertyChanged, The Anders Hejlsberg Way
    2. INotifyPropertyChanged, The .NET 4.5 Way
    3. INotifyPropertyChanged, The .NET 4.5 Way - Revisited
    4. INotifyPropertyChanged, The .NET 4.6 Way

    With the release of Visual Studio 2015 & .NET 4.6, we have a new version of the C# compiler and along with it a new version of C# [version 6] that includes new language features that we can leverage to improve the implementation of INotifyPropertyChanged in our applications.

    Specifically, with the addition of the Null-conditional Operators in C# 6, we can simplify the implementation of our OnPropertyChanged method from:

    protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        PropertyChangedEventHandler eventHandler = this.PropertyChanged;
        if (eventHandler != null)
        {
            eventHandler(this, new PropertyChangedEventArgs(propertyName));
        }
    }
    

    to:

    protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        this.PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
    

    This works because the new Null-conditional Operators are thread-safe:

    Another use for the null-condition member access is invoking delegates in a thread-safe way with much less code. ... The new way is thread-safe because the compiler generates code to evaluate PropertyChanged one time only, keeping the result in a temporary variable.

    While the CallerMemberName attribute in our OnPropertyChanged method implementation will handle most cases, when we do need to manually specify the name of a property in C# 6, we no longer need to resort to the use of magic strings or expression trees. Rather, we can now use the new nameof() operator keyword to pass the property name:

    OnPropertyChanged(nameof(MyProperty));
    

    These changes have the added bonus of being usable when you're targeting prior versions of .NET as well (though you must have the .NET 4.6 tooling installed). This means we don't have to update our existing applications and libraries to .NET 4.6 just the take advantage of the new language features.

    The code in this post, except for the CallerMemberName attribute, works in Visual Studio 2015 when targeting framework versions all the way down to .NET 2.0. The use of the CallerMemberName attribute requires a target of .NET 4.5 or higher.

    Using these features, our implementation of the BindableBase class now looks like this:

    using System.ComponentModel;
    using System.Runtime.CompilerServices;
    
    /// <summary>
    ///     Implementation of <see cref="INotifyPropertyChanged" /> to simplify models.
    /// </summary>
    public abstract class BindableBase : INotifyPropertyChanged
    {
        /// <summary>
        ///     Multicast event for property change notifications.
        /// </summary>
        public event PropertyChangedEventHandler PropertyChanged;
    
        /// <summary>
        ///     Checks if a property already matches a desired value.  Sets the property and
        ///     notifies listeners only when necessary.
        /// </summary>
        /// <typeparam name="T">Type of the property.</typeparam>
        /// <param name="storage">Reference to a property with both getter and setter.</param>
        /// <param name="value">Desired value for the property.</param>
        /// <param name="propertyName">
        ///     Name of the property used to notify listeners.  This
        ///     value is optional and can be provided automatically when invoked from compilers that
        ///     support CallerMemberName.
        /// </param>
        /// <returns>
        ///     True if the value was changed, false if the existing value matched the
        ///     desired value.
        /// </returns>
        protected bool SetProperty<T>(ref T storage, T value, [CallerMemberName] string propertyName = null)
        {
            if (Equals(storage, value))
            {
                return false;
            }
    
            storage = value;
            this.OnPropertyChanged(propertyName);
            return true;
        }
    
        /// <summary>
        ///     Notifies listeners that a property value has changed.
        /// </summary>
        /// <param name="propertyName">
        ///     Name of the property used to notify listeners.  This
        ///     value is optional and can be provided automatically when invoked from compilers
        ///     that support <see cref="CallerMemberNameAttribute" />.
        /// </param>
        protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            this.PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
    }
    

    Null-conditional Operators and the nameof() operator are both fantastic new additions. While you're taking advantage of them, don't forget to familiarize yourself with all of the new language features in C# 6.

    Bonus: If you wanted to implement BindableBase while targeting .NET 2.0 to .NET 4.0, it would look like this.

  • Supported PCL Profiles in Xamarin for Visual Studio 2.0 posted on 14 May 2014

    Xamarin is continuing their rapid development pace and has released several updates to their Xamarin for Visual Studio tools since my last post on PCL Profiles & Xamarin.

    Most notably, if you're on the Alpha or Beta channel, they have released a 2.0 build of Xamarin for Visual Studio which unifies the iOS and Android installers into a single package and adds support for several new PCL profiles.

    Here are all of the currently supported PCL profiles in the 2.0 release (No SupportedFramework Fix required):

    Profile 5   (.NET Framework 4,     Windows 8)
    Profile 6   (.NET Framework 4.0.3, Windows 8)
    Profile 7   (.NET Framework 4.5,   Windows 8)
    Profile 14  (.NET Framework 4,     Silverlight 5)
    Profile 19  (.NET Framework 4.0.3, Silverlight 5)
    Profile 24  (.NET Framework 4.5,   Silverlight 5)
    Profile 37  (.NET Framework 4,     Silverlight 5, Windows 8)
    Profile 42  (.NET Framework 4.0.3, Silverlight 5, Windows 8)
    Profile 47  (.NET Framework 4.5,   Silverlight 5, Windows 8)
    Profile 49  (.NET Framework 4.5,   Windows Phone Silverlight 8)
    Profile 78  (.NET Framework 4.5,   Windows 8, Windows Phone Silverlight 8)
    Profile 92  (.NET Framework 4,     Windows 8, Windows Phone 8.1)
    Profile 102 (.NET Framework 4.0.3, Windows 8, Windows Phone 8.1)
    Profile 111 (.NET Framework 4.5,   Windows 8, Windows Phone 8.1)
    Profile 136 (.NET Framework 4,     Silverlight 5, Windows 8, Windows Phone Silverlight 8)
    Profile 147 (.NET Framework 4.0.3, Silverlight 5, Windows 8, Windows Phone Silverlight 8)
    Profile 158 (.NET Framework 4.5,   Silverlight 5, Windows 8, Windows Phone Silverlight 8)
    Profile 225 (.NET Framework 4,     Silverlight 5, Windows 8, Windows Phone 8.1)
    Profile 255 (.NET Framework 4.5,   Silverlight 5, Windows 8, Windows Phone 8.1)
    Profile 259 (.NET Framework 4.5,   Windows 8, Windows Phone 8.1, Windows Phone Silverlight 8)
    Profile 328 (.NET Framework 4,     Silverlight 5, Windows 8, Windows Phone 8.1, Windows Phone Silverlight 8)
    Profile 336 (.NET Framework 4.0.3, Silverlight 5, Windows 8, Windows Phone 8.1, Windows Phone Silverlight 8)
    Profile 344 (.NET Framework 4.5,   Silverlight 5, Windows 8, Windows Phone 8.1, Windows Phone Silverlight 8)
    

    Now what profile should you choose?

    My advice:

    • If you're starting a brand new cross platform mobile .NET app today and looking to use a PCL for common code in your app, you should probably use Profile 111 as it offers access to a lot of APIs not available in the other profiles.
    • If you're creating a library for consumption by a broad range of existing cross platform mobile .NET applications, you should look at Profile 259 as it has broad reach and access to .NET 4.5 functionality.

    If you're looking for a complete list of all PCL profiles, take a look at this great reference created by Stephen Cleary.

  • Notes on Using Various PCL Profiles with Xamarin posted on 16 Apr 2014

    Below are some notes that I took today while researching various PCL profiles and their compatibility for use with Xamarin in Visual Studio. It's by no means complete, and the known limitations for Xamarin.Android and Xamarin.iOS apply in addition to what I noted below.

    Profile 151 (.NET 4.5.1, Windows 8.1, Windows Phone 8.1)

    • Works after using the SupportedFramework Fix with Xamarin 4.0+
    • Doesn't work yet with the tooling (even with the SupportedFramework Fix)
      • Requires updated façade assemblies for MonoDroid & MonoTouch as well as the SupportedFramework targets
      • Likely to be supported in the future
    • This is a slightly updated version of Profile 111
      • Several assemblies updated to newer versions
        • System.Diagnostics.Tracing
        • System.Runtime
        • System.Runtime.InteropServices
      • Access to System.Threading.Timer which isn’t available in Profile 111
    • Most current and forward looking profile (at the expense of compatibility)

    Profile 111 (.NET 4.5, Windows 8.0, Windows Phone 8.1)

    Profile 259 (.NET 4.5, Windows 8.0, Windows Phone Silverlight 8.0, Windows Phone 8.1)

    Profile 344 (.NET 4.5, Windows 8.0, Windows Phone Silverlight 8.0, Silverlight 5, Windows Phone 8.1)

    Profile 78 (.NET 4.5, Windows 8.0, Windows Phone Silverlight 8.0)

    • Works out of the box
    • Very good Xamarin compatibility
    • This is Xamarin's current preferred profile, but that will likely change to 259 in the future

    Profile 158 (.NET 4.5, Windows 8.0, Windows Phone Silverlight 8.0, Silverlight 5)

    • Works out of the box
    • Very good Xamarin compatibility
    • Broad reach
    • Async/Await requires use of a NuGet package (Due to SL5 support)
  • Fix for Creating PCLs in Visual Studio That Target Windows Phone 8.1 and Xamarin posted on 10 Apr 2014

    Trouble in Paradise

    With BUILD over and the Visual Studio Update 2 RC released, many of us are playing with the new Windows Phone 8.1 bits.

    However, if you're using Xamarin in Visual Studio and you've tried to create a new (or update an existing) Portable Class Library that targets both the new Windows Phone 8.1 application type and Xamarin iOS/Android, you may have encountered a problem:

    Visual Studio PCL Error

    At this moment, Xamarin is aware of the issue and a fix will be coming in an updated release of the Xamarin tools for Visual Studio, but if you're impatient like me and want/need to use the bits RIGHT NOW, there is in fact a workaround...

    A New Hope

    So what do we need to do? Turns out the workaround is pretty straight forward.

    Open up the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile78\SupportedFrameworks folder (changing the drive letter accordingly) and select Xamarin.Android.xml and Xamarin.iOS.xml.

    Supported Framework Files Source

    If you only have Xamarin for iOS or Xamarin for Android installed, you may only see one of these 2 files and that's perfectly fine.

    Now we're going to copy the file(s) to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile259\SupportedFrameworks. You may be prompted for administrator rights to do this, just click ok.

    Supported Framework Files Source

    So, why did we choose Profile 259 anyway?

    Well, prior to Visual Studio 2013 Update 2, Xamarin's best supported (and favorite) profile was PCL profile 78.

    PCL Profile 259 is Profile 78 + Windows Phone 8.1 (and the "new profile 78") which should give us the highest amount of compatibility.

    At this point close Visual Studio (if it was still open) and then launch it again.

    Now if we select .NET Framework 4.5, Windows 8, Windows Phone Silverlight 8, Windows Phone 8.1, Xamarin.Android, and/or Xamarin.iOS everything should work...

    Supported Framework Files Source

    Supported Framework Files Source

    Epilogue

    If you can't use Profile 259 because you need to support different platform targets, this fix works for other profile numbers as well, though Xamarin compatibility may be dimished as the PCL Profile may support some functionality that one or more of the Xamarin platforms can't (ex. dynamic).

    A good example would be if you also needed to target Silverlight 5. You would copy the two xml files into the .NETPortable\v4.0\Profile\Profile344 folder (This is also a very good profile for Xamarin development).

    Credits

    This fix comes courtesy of Oren Novotny, so if it helps you, be sure to thank (and follow) him!

  • Announcing AllAboutXamarin.com and @AllAboutXamarin posted on 28 Feb 2014

    Some of you may have noticed that I silently launched a new link blog and Twitter account on Monday. Today I'm formally announcing both: Say hello to http://AllAboutXamarin.com and @AllAboutXamarin!

    AllAboutXamarin on Twitter

    I've been working on a very large native cross platform application for a client that runs on iOS, Android, Windows Phone, and Windows Store, leveraging the Xamarin tools. A natural extension of that process has been searching for news and content about what is going on in the Xamarin developer community.

    So following in the footsteps of http://WindowsAppDev.com and @WindowsAppDev, my hope is that the new site and and Twitter feed will be a valuable resource for the Xamarin community.

    And fear not, I won't be neglecting my Windows developer readership. My family, maybe, but not you dear mobile app developer community. (: