MVX=0 WPF/Mac: A first MvvmCross Application (MVX+1 days of MvvmCross)

MVX=0 WPF/Mac: A first MvvmCross Application (MVX+1 days of MvvmCross)

Further to some feedback on the first couple of posts in the MVX+1 series (MVX=0, MVX=0F and MVX=1), I’ve gone back and added WPF and Mac support to the FirstDemo to show just how powerful MvvmCross is. I’ll cover very briefly here how to add these project types and then I’ll be updating the TipCalc post to include the basics for WPF and Mac setup in there too.

Let’s start with WPF:

  1. Add a WPF App (.NET Framework) called FirstDemo.Wpf
    image
  2. Add a reference to MvvmCross NuGet package
  3. Add reference to FirstDemo.Core project
  4. Add ProxyMvxApplication to App.xaml.cs
    public abstract class ProxyMvxApplication : MvxApplication<MvxWpfSetup<Core.App>, Core.App> { }
  5. Update App class in both App.xaml and App.xaml.cs to inherit from ProxyMvxApplication
  6. Remove all code in the App class (in App.xaml.cs) except for the constructor with call to InitializeComponent
    public App()
    {
         InitializeComponent();
    }
  7. Update MainWindow in both MainWindow.xaml and MainWindow.xaml.cs to inherit from MvxWindow
  8. Create Views folder
  9. Add new User Control (WPF) called FirstView.xaml
  10. Update FirstView in both FirstView.xaml and FirstView.xaml.cs to inherit from MvxWpfView
  11. Add XAML to FirstView.xaml
    <StackPanel Margin=”12,12,12,12″>
         <TextBox Text=”{Binding FirstName, Mode=TwoWay}”></TextBox>
         <TextBox Text=”{Binding LastName, Mode=TwoWay}”></TextBox>
         <TextBlock Text=”{Binding FullName}”></TextBlock>
    </StackPanel>

You should now be able to build and run the WPF application – notice how little code we have to add/change in order to get MvvmCross to work!

Next up is Mac which at the moment can only be done on a Mac (almost no surprises there – it’s the same as not being able to do UWP development on a Mac I guess):

  1. Add a Cocoa App called FirstDemo.Mac
    image
  2. Add a reference to MvvmCross NuGet package
  3. Add reference to FirstDemo.Core project
  4. At this point I would recommend unloading your project, editing the csproj file manually to removed the legacy nuget reference and add the following ItemGroup. Also remove the reference to package.config, remove the actual package.config file and delete both bin and obj folders. Reload the Mac project and force a rebuild.
    <ItemGroup>
       <PackageReference Include=”MvvmCross” Version=”6.0.0″ />
    </ItemGroup>
  5. Update AppDelegate to inherit from MvxApplicationDelegate
    [Register(“AppDelegate”)]
    public class AppDelegate: MvxApplicationDelegate<MvxMacSetup<App>, App>
    {
         public override void DidFinishLaunching(NSNotification notification)
         {
             MvxMacSetupSingleton.EnsureSingletonAvailable(this, MainWindow).EnsureInitialized();
             RunAppStart();
            // Due to a bug, do not call base DidFinishLaunching
             //base.DidFinishLaunching(notification);
         }
    }
    Note: There is a bug at the moment where if you don’t override DidFinishLaunching the application will crash on startup
  6. Open main.storyboard – this should open the storyboard in the XCode designer
  7. Select the existing view controller and set the Class and Storyboard ID to FirstView
    image
  8. Make sure the FirstView name change has been saved; return to VS for Mac and confirm that files FirstView.cs and FirstView.designer.cs have been created. If these have not been created, I would suggest doing a rebuild of your project to make sure the changes to the storyboard have been processed and the appropriate designer files created.
  9. From the Object Library drag two TextField and a Label across onto the design surface
    image
  10. Open Project navigator and make sure you have FirstView.h and FirstView.m. If you don’t I would suggest closing both XCode and VS for Mac, deleting the bin and obj folder from within the FirstDemo.Mac folder and reopening the solution in VS for Mac. Rebuild the Mac project and then launch XCode by double clicking on main.storyboard.
    image
  11. Hide both Project navigator (left pane) and Utilities (right pane) and show the Assistant Editor (the icon button that has linked circles in top right corner of XCode)
  12. From the navigator bar in the Assistant Editor, select Manual –> FirstView.Mac –> FirstView.h
    image
  13. Right-click on the first TextField
    image
  14. Click and drag the circle next to New Referencing Outlet across onto the FirstView.h immediately before the @End. When you release, you should be prompted to complete information about the new Outlet where you can specify the Name, textEditFirst, which will be the name of the backing variable you’ll be able to use to reference the TextField in code
    image
  15. Repeat the previous step for the second TextField, textEditSecond, and the Label, labelFull.
  16. Update FirstView.cs to add the MvxFromStoryboard attribute, change the base class to MvxViewController and add data binding using the CreateBindingSet extension
    [MvxFromStoryboard(“Main”)]
    public partial class FirstView : MvxViewController<FirstViewModel>
    {
         public FirstView(IntPtr handle) : base(handle)
         {
         }

  17.     public override void ViewDidLoad()
         {
             base.ViewDidLoad();
             var set = this.CreateBindingSet<FirstView, FirstViewModel>();
             set.Bind(textEditFirst).To(vm => vm.FirstName);
             set.Bind(textEditSecond).To(vm => vm.LastName);
             set.Bind(labelFull).To(vm => vm.FullName);
             set.Apply();
         }
    }

And there you have it – build and run your Mac FirstDemo application

    Adding Logging to Client Applications using MetroLog not NLog

    Adding Logging to Client Applications using MetroLog not NLog

    I wanted to add some logging to my set of applications and was somewhat disappointed to discover the complete lack of PCL support in NLog. After a quick search to find out what others are using I came across MetroLog which seems to be very similar in a lot of regards to NLog (in fact they claim the API surface is very similar indeed). I went to install the NuGet package…

    image

    and noticed that my Core library (a PCL) wasn’t in the list. Clearly my PCL profile doesn’t match one of the supported profiles which is a bit painful. However, it does support all my client application types so I was happy at least to use MetroLog.

    image

    I did have a couple of issues installing the NuGet package, namely Visual Studio decided to crash mid way through installing the packages. This meant I had to manually install Microsoft.Bcl.Compression which is a dependency for the Windows Phone 8.0 project, and then uninstall and reinstall the support for the Windows and Desktop projects.

    After all this I was building successfully again so it was time to think about how to structure the logging support. Clearly with logging I want it to be a simple as possible and yet accessible virtually anywhere within the application. I want to define a service that is available within my Core library in a similar way to my IDataService and ISyncService implementation. I also wanted the log output to be written out to a sqlite database file for ease of access (there are plenty of third party tools capable of viewing sqlite db files) but rather than use the SqliteTarget that comes with MetroLog I felt I had to write my own (as you do). Luckily this whole process is relatively simple.

    I start by creating an ILogWriterService interface which will provide the low level API for writing a LogEntry to a local Mobile Service sqlite table (I’m going to use the same process that is used to cache my synchronized data, except for the time being at least, the data won’t be synchronized anywhere).

    public interface ILogWriterService
    {

        IMobileServiceSyncTable<LogEntry> LogTable { get; }
        Task Initialize();
    }

    public class LogEntry : BaseEntityData
    {
        public DateTime LogDateTime { get; set; }
        public string Entry { get; set; }
    }

    public class LogWriterService : ILogWriterService
    {
        private readonly MobileServiceClient mobileService = new MobileServiceClient(Constants.MobileServiceRootUri);

        private IMobileServiceClient MobileService
        {
            get { return mobileService; }
        }

        public IMobileServiceSyncTable<LogEntry> LogTable
        {
            get { return MobileService.GetSyncTable<LogEntry>(); }
        }

        public async Task Initialize()
        {
            var data = new MobileServiceSQLiteStore(“log.db”);
            data.DefineTable<LogEntry>();

            await MobileService.SyncContext.InitializeAsync(data, new MobileServiceSyncHandler());
        }
    }

    Next I define the high level service interface, ILogService:

    public interface ILogService
    {
        void Debug(string message);

        void Exception(string message, Exception ex);
    }

    So far, all of these classes have been in the Core library. However, the implementation of the ILogService has to be in the Shared.Client project as it needs to be used by all the client projects.

    public class LogService : ILogService
    {
        public ILogWriterService Writer { get; set; }

        public ILogger Logger { get; set; }

        public LogService(ILogWriterService writer)
        {
            Writer = writer;
            var target = new MobileServiceTarget(Writer);

            LogManagerFactory.DefaultConfiguration.AddTarget(LogLevel.Debug, target);

            Logger = LogManagerFactory.DefaultLogManager.GetLogger(“Default”);
        }

        public void Debug(string message)
        {
            Logger.Debug(message);
        }

        public void Exception(string message, Exception ex)
        {
            Logger.Error(message, ex);
        }
    }

    As you can see the implementation sets up the MetroLog logger but uses a custom MobileServiceTarget as the destination. This is implemented as follows:

    public class MobileServiceTarget : Target
    {
        public ILogWriterService Writer { get; set; }
        public MobileServiceTarget(ILogWriterService writer)
            : base(new SingleLineLayout())
        {
            Writer = writer;
        }

        private bool InitCompleted { get; set; }
        protected async override Task<LogWriteOperation> WriteAsyncCore(LogWriteContext context, LogEventInfo entry)
        {
            try
            {
                if (!InitCompleted)
                {
                    await Writer.Initialize();
                    InitCompleted = true;
                }
                var log = new LogEntry { LogDateTime = DateTime.Now, Entry = entry.ToJson() };
                await Writer.LogTable.InsertAsync(log);
                return new LogWriteOperation(this, entry, true);
            }
            catch (Exception ex)
            {
                return new LogWriteOperation(this, entry, false);
            }
        }
    }

    I of course need to register the implementations with Autofac:

    builder.RegisterType<LogWriterService>().As<ILogWriterService>();
    builder.RegisterType<LogService>().As<ILogService>();

    And the last thing is a static helper class that makes logging for two core scenarios really easy:

    public static class LogHelper
    {
        public static void Log<TEntity>(TEntity entity, [CallerMemberName] string caller = null)
        {
            var json = JsonConvert.SerializeObject(entity);
            Log(typeof(TEntity).Name + “: ” + json, caller);
        }

        public static void Log(string message = null, [CallerMemberName] string caller = null)
        {
            try
            {
                InternalWriteLog(“[” + caller + “] ” + message);
            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex.Message);
            }
        }

        public static void Log(this Exception ex, string message = null, [CallerMemberName] string caller = null)
        {
            try
            {
                Debug.WriteLine(“Exception ({0}): {1}”, caller, ex.Message);
                InternalWriteException(caller + “: ” + message, ex);
            }
            catch (Exception ext)
            {
                Debug.WriteLine(ext.Message);
            }
        }

        private static ILogService logService;

        private static ILogService LogService
        {
            get
            {
                if (logService == null)
                {
                    logService = ServiceLocator.Current.GetInstance<ILogService>();

                }
                return logService;
            }
        }

        private static void InternalWriteLog(string message)
        {
            try
            {

                LogService.Debug(message);
            }
            catch (Exception ext)
            {
                Debug.WriteLine(ext.Message);
            }
        }

        private static void InternalWriteException(string message, Exception ex)
        {
            try
            {
                LogService.Exception(message, ex);
            }
            catch (Exception ext)
            {
                Debug.WriteLine(ext.Message);
            }
        }
    }

    The first scenario is a simple string output eg:

    LogHelper.Log(“Startup complete”);

    The second is logging the output of an Exception:

    try
    {
       …
    }
    catch (Exception ex)
    {
        ex.Log();
    }

    Note that the Exception logging also does a Debug.WriteLine which is convenient during development to pick up any issues in the Output window.

    Navigation in the WPF Application Between View Models

    Navigation in the WPF Application Between View Models

    In my previous post I showed adding a INavigateService to facilitate navigation between view models. This included an implementation of the service for Universal applications. For WPF the implementation looks very similar:

    public class WPFNavigationService : CoreNavigateService<Page>
    {
        protected override void NavigateToView(Type viewType)
        {
            (App.Current.MainWindow.Content as Frame).Navigate(new Uri(“/Pages/” + viewType.Name + “.xaml”, UriKind.RelativeOrAbsolute));
        }
    }

    Note that this assumes that pages are in the Pages folder of the project.

    The other change that is required is that the WPF application needs to have a Frame which can be used to navigate between pages. So, the MainWindow now looks like

    <Window x_Class=”RealEstateInspector.Desktop.MainWindow”
            http://schemas.microsoft.com/winfx/2006/xaml/presentation"”>http://schemas.microsoft.com/winfx/2006/xaml/presentation”
            http://schemas.microsoft.com/winfx/2006/xaml"”>http://schemas.microsoft.com/winfx/2006/xaml”
            Title=”MainWindow” Height=”350″ Width=”525″
            >
        <Frame Source=”/Pages/MainPage.xaml” />
    </Window>

    All the content that was in the MainWindow is now in MainPage. And the type registration at application startup is getting more complex:

    public void ApplicationStartup()
    {
        CoreApplication.Startup(builder =>
        {

            builder.RegisterType<SignalRFactory>().As<ISignalR>();
    #if NETFX_CORE
            builder.RegisterType<UniversalUIContext>().As<IUIContext>();
            builder.RegisterType<WindowsPlatformNavigationService>().SingleInstance().As<INavigateService>();

    #elif DESKTOP
            builder.RegisterType<WPFNavigationService>().SingleInstance().As<INavigateService>();
    #endif
        });

    #if NETFX_CORE
        var navService = ServiceLocator.Current.GetInstance<INavigateService>() as WindowsPlatformNavigationService;
    #elif DESKTOP
        var navService = ServiceLocator.Current.GetInstance<INavigateService>() as WPFNavigationService;
    #endif
    #if NETFX_CORE || DESKTOP
        navService.Register<MainViewModel, MainPage>();
        navService.Register<SecondViewModel, SecondPage>();
    #endif
    }

    This creates a navigation bar which allows the user to navigate back between pages:

    image

    ViewModel Refactoring, INotifyPropertyChanged and Running on UI Context with Dispatcher

    ViewModel Refactoring, INotifyPropertyChanged and Running on UI Context with Dispatcher

    In a previous post I showed how to use SignalR as one option for providing feedback to the client application during a long running service operation. However, I didn’t display this on the UI because that would have made the blog post long and complicated as I tried to explain propagating a change from a non-UI thread, back onto the UI thread so it could be displayed within the app. In this post I’m going to do just that – what’s interesting is that each platform handles this scenario slightly different with some caring about thread affinity, whilst others do not.

    Firstly, I’ll update the layout to include a TextBlock that’s going to display the progress:

    <TextBlock Text=”{Binding Progress}” />

    In this case databinding to the Progress property on the MainViewModel:

    private string progress;
    public string Progress
    {
        get { return progress; }
        set
        {
            if (Progress == value) return;
            progress = value;
            OnPropertyChanged();
        }
    }

    Note that as this property changes it calls the OnPropertyChanged method which will be used to raise the PropertyChanged event specified in the INotifyPropertyChanged interface – this is what the XAML data binding framework uses to detect when bound properties are changed. In this case I’m going to implement this interface in BaseViewModel, and have MainViewModel inherit from BaseViewModel, rather than implement it in every view model.

    public class MainViewModel:BaseViewModel  { … }

    public class BaseViewModel:INotifyPropertyChanged
    {
       
    public event PropertyChangedEventHandler PropertyChanged;

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

        }
    }

    Now, let’s modify the delegate that gets invoked when we receive an update from the service. Previously we just had Debug.WriteLine(msg), let’s change that to  Progress=msg. When you run this in your Universal Windows application – BANG – Exception due to an attempt to update the UI (ie the Text attribute on the TextBlock) from a non-UI thread. Interestingly doing the same thing in the WPF application doesn’t throw the same exception. In order to update the Progress property, we first need to jump back onto the UI thread, which is fine, if we were working directly with the Page/View. However, we don’t have any notion of a Dispatcher, UI threads etc from within the MainViewModel. This sounds like another scenario for a dependency injected implementation, so here goes:

    My BaseViewModel is extended to include a UIContext object:

    private readonly UIContext context=new UIContext();

    public UIContext UIContext

    {
        get { return context; }
    }

    The UIContext object wraps and abstracts away the loading of an implementation of IUIContext:

    public interface IUIContext
    {
        Task RunOnUIThreadAsync(Func<Task> action);
    }

    public class UIContext
    {
        private IUIContext runContext;
        private IUIContext RunContext
        {
            get
            {
                if (runContext == null)
                {
                    runContext = ServiceLocator.Current.GetInstance<IUIContext>();

                }
                return runContext;
            }
        }

        public async Task RunAsync(Action action)
        {
            await RunAsync(async () => action());
        }

        public async Task RunAsync(Func<Task> action)
        {
            var context = RunContext;
            await context.RunOnUIThreadAsync(action);
        }
    }

    Of course, we now need an implementation of IUIContext for our Universal Windows application:

    public class UniversalUIContext : IUIContext
    {
        public async Task RunOnUIThreadAsync(Func<Task> action)
        {
            await CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(CoreDispatcherPriority.Normal,async  () => await action());
        }
    }

    And this needs to be registered with Autofac in the ClientApplicationCore – note the use of the NETFX_CORE compilation attribute.

    CoreApplication.Startup(builder =>
    {
        builder.RegisterType<SignalRFactory>().As<ISignalR>();
    #if NETFX_CORE
        builder.RegisterType<UniversalUIContext>().As<IUIContext>();
    #endif
    });

    And finally I need to go back to my initial progress statement and update it from msg => Progress = msg, to the following:

    async msg =>
        await UIContext.RunAsync(() =>
        {
            Progress = msg;
        })

    This issue isn’t specific to Universal applications, and you should always make sure you have access to the UI thread when making UI changes (such as updating data bound properties).

    Debugging Azure Active Directory Authentication with Azure Mobile Service .NET Backend When Running Locally

    Debugging Azure Active Directory Authentication with Azure Mobile Service .NET Backend When Running Locally

    In a recent project one of the more challenging things was to debug the Azure Mobile Services (AMS) when running locally. For the most part it was pretty straight forward as a lot of the requests, whilst they required a user to be authenticated, the returned data wasn’t contingent on who the user was. When you run Azure Mobile Services locally, which you can with the .NET backend but not with the Node.js backend, by default it doesn’t enforce any of the security requirements. This makes it easy to debug scenarios where it doesn’t matter who the user is but very hard for those scenarios where the data needs to be altered based on who the user is, particularly if the user is being authenticated using Azure Active Directory (AAD). In this post I’ll walk through getting debugging to run locally.

    The first thing I need to do is to configure the Mobile Service to enforce the same security when running locally, as if it were running in Azure. I do this by adding the following immediately following the ServiceConfig.Initialize line:

    // This tells the local mobile service project to run as if it is being hosted in Azure,
    // including honoring the AuthorizeLevel settings. Without this setting, all HTTP requests to
    // localhost are permitted without authentication despite the AuthorizeLevel setting.
    config.SetIsHosted(true);

    Side Note (feel free to skip over this section if you’re not interested on how I attempted to get this to work)

    My initial approach was to use what I new about the way AAD connects with AMS which involves an application within AAD that defines the relationship between the native client (which is authenticating) and the AMS (which is the resource it is requesting access to). As my AMS is running locally it is hosted at http://localhost:51539/ I thought that I needed to create another AAD Web application pointing at http://localhost:51539/login/aad eg

    image

    And then in the Native Client AAD application I had to delegate permissions to the new AAD Web application eg

    image

    In the native application, in this case my WPF application, I changed both the resource url for the AAD authentication and the mobile services url to use http://localhost:51539/ ie http://localhost:51539/login/aad for the resource url and just http://localhost:51539/ for the mobile services url. This seemed to work correctly initially as it displayed the sign in prompt, I could sign in and get back an AAD access token. Unfortunately when this was passed to the AMS it failed miserably with an unauthorised exception.

    Note: I actually feel what I did here was correct that that the Mobile Services team are incorrectly validating the claims based on the illusion that the local services is being hosted in the cloud. This means you actually need to authenticate with AAD as if you were requesting access to the resource https://realestateinspector.azure-mobile.net/login/aad and then actually connect to the locally running mobile service.

    End of Side Note – Here’s how you really do it

    Ok, so you DON’T need to change the url that is being specified as the resource when signing into AAD. However, you DO need to change the url that is used when creating the instance of the mobile service client. My constants file now looks like this:

    #if DEBUG
    #define DEBUGLOCAL
    #endif

    public static class Constants
    {
        public const string ADTenant = “realestateinspector.onmicrosoft.com”;
        public const string ADAuthority=”
    https://login.windows.net/” + ADTenant;

        public const string ADNativeClientApplicationClientId = “a5a10ee9-f871-4bde-997f-3f1c323fefa5”;

        public const string ADRedirectUri = “http://builttoroam.com”;

    #if DEBUGLOCAL
        public const string ActualMobileServiceRootUri = “
    https://realestateinspector.azure-mobile.net/”;
        public const string MobileServiceRootUri = “http://localhost:51539/”;
        public const string MobileServiceAppIdUri = ActualMobileServiceRootUri + “login/aad”;
    #else
        public const string MobileServiceRootUri = “
    https://realestateinspector.azure-mobile.net/”;
        public const string MobileServiceAppIdUri = MobileServiceRootUri + “login/aad”;
    #endif
    }

    Note that I’ve used an inline compilation constant to allow me to switch from debugging against the local services versus those hosted in the cloud.

    If you attempt to run this, the user will be directed to authenticate using the AAD signin with a resource https://realestateinspector.azure-mobile.net/login/aad and then the application will attempt to login to the Mobile Service running locally at http://localhost:51539/ (Note – I typically set both the native client project (in this case the WPF application) and the Mobile Service project as start projects). However, you’ll still get an unauthorized exception because the Mobile Service actual does verify that the claims in the access token returned from AAD match the settings of the Mobile Services (excluding the base url that the service is being run from – see my early argument why this imho is the wrong approach). Let’s first take a look at the access token using the site http://jwt.io.

    image 

    If you look in the Web.config file for the Mobile service you’ll see that there is a list of Mobile Service settings in the appSettings section. The first of which is typically the MS_MobileServiceName and I’m guessing it’s this setting that is being used to validate that the claim in the token is for the right mobile serivce – in the token you can see that the resource is https://realestateinspector.azure-mobile.net/login/aad where the only piece that varies between Mobile Services is the service name.

    <add key=”MS_MobileServiceName” value=”realestateinspector” />
    The next thing to look at is in the actual login request that the mobile service client library makes:

    POST: https://realestateinspector.azure-mobile.net/login/aad
    X-ZUMO-INSTALLATION-ID: c2ac49d1-af97-472b-af61-bfb06663f137
    X-ZUMO-APPLICATION: wpxaIplpeXtknXQhqXiVlZAPYQEBcg12
    X-ZUMO-AUTH: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ1cm46bWljcm9zb2Z0OndpbmRvd3MtYXp1cmU6enVtbyIsImF1ZCI6InVybjptaWNyb3NvZnQ6d2luZG93cy1henVyZTp6dW1vIiwibmJmIjoxNDIyMDkxOTY3LCJleHAiOjE0MjIwOTU0OTYsInVybjptaWNyb3NvZnQ6Y3JlZGVudGlhbHMiOiJ7XCJ0ZW5hbnRJZFwiOlwiZTY4OGQ1OTQtODY0My00YmRmLTllNGMtMGJlOGJjYmM2NDVmXCIsXCJvYmplY3RJZFwiOlwiYWJkNzc5MjgtNDFkMS00YzNjLThmNmYtMmE1NmQ4NDRkMDVlXCIsXCJhY2Nlc3NUb2tlblwiOlwiZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOaUlzSW5nMWRDSTZJbXR5YVUxUVpHMUNkbmcyT0hOclZEZ3RiVkJCUWpOQ2MyVmxRU0o5LmV5SmhkV1FpT2lKb2RIUndjem92TDNKbFlXeGxjM1JoZEdWcGJuTndaV04wYjNJdVlYcDFjbVV0Ylc5aWFXeGxMbTVsZEM5c2IyZHBiaTloWVdRaUxDSnBjM01pT2lKb2RIUndjem92TDNOMGN5NTNhVzVrYjNkekxtNWxkQzlsTmpnNFpEVTVOQzA0TmpRekxUUmlaR1l0T1dVMFl5MHdZbVU0WW1OaVl6WTBOV1l2SWl3aWFXRjBJam94TkRJeU1Ea3hOalUyTENKdVltWWlPakUwTWpJd09URTJOVFlzSW1WNGNDSTZNVFF5TWpBNU5UVTFOaXdpZG1WeUlqb2lNUzR3SWl3aWRHbGtJam9pWlRZNE9HUTFPVFF0T0RZME15MDBZbVJtTFRsbE5HTXRNR0psT0dKalltTTJORFZtSWl3aVlXMXlJanBiSW5CM1pDSmRMQ0p2YVdRaU9pSmhZbVEzTnpreU9DMDBNV1F4TFRSak0yTXRPR1kyWmkweVlUVTJaRGcwTkdRd05XVWlMQ0oxY0c0aU9pSnBibk53WldOMGIzSkFjbVZoYkdWemRHRjBaV2x1YzNCbFkzUnZjaTV2Ym0xcFkzSnZjMjltZEM1amIyMGlMQ0p6ZFdJaU9pSm5WMlJUY0VwbllqSnBUbkpyWm5wbVlUQlViWGhPTFZGeU0yMXFhamhoY0ZoZlYxbG5lVGRrVDNOUklpd2libUZ0WlNJNklrbHVjM0JsWTNSdmNpSXNJblZ1YVhGMVpWOXVZVzFsSWpvaWFXNXpjR1ZqZEc5eVFISmxZV3hsYzNSaGRHVnBibk53WldOMGIzSXViMjV0YVdOeWIzTnZablF1WTI5dElpd2lZWEJ3YVdRaU9pSmhOV0V4TUdWbE9TMW1PRGN4TFRSaVpHVXRPVGszWmkwelpqRmpNekl6Wm1WbVlUVWlMQ0poY0hCcFpHRmpjaUk2SWpBaUxDSnpZM0FpT2lKMWMyVnlYMmx0Y0dWeWMyOXVZWFJwYjI0aUxDSmhZM0lpT2lJeEluMC5IVEhlUEFEcW5XYjE2ZTdwYTQ1VkppdFlTV2pvanZzaEwyZ3I4cTR3S1k2QkpWNF9INXBoQklmQ1p3RUtGeU05MlpQWkpza1NDVkl5QlNvNnU0eTgyUlJKcWxmVW9NN3hjRG1zZ0dOVlNYZzhoOGhJWm56X1ZIcGg4ZUp4TXRvZ0VrR2tZWXFld0R5Wi1zWlVTaVZ5ckhpZWlCd2Qzd2M4T0hQaDRXeGUwbUh6OHItekZoOGtmY2lQWW9KRkJ3aGczVGFaZ3hMQWJnaWVMUG83V1ZBUFpIUjV5SG1UaW02RXhQOGdUejQ0WmFiYTI3QnpISUI1dV9oa1F2QWlmU2M2blBXcVZwcC1CamZQM25mbXQwai0xemkwb1RHMVlvMjZNQzNXSHhCTUdKbGpKcVg3UmhBenV4anZESDFyRG5PeE9YaldSVk1qV2gyNzRXUjdXa0YwM0FcIn0iLCJ1aWQiOiJBYWQ6Z1dkU3BKZ2IyaU5ya2Z6ZmEwVG14Ti1RcjNtamo4YXBYX1dZZ3k3ZE9zUSIsInZlciI6IjIifQ.s6fjFOzFhdvvYgL3yD3lUEiUcxALg-avOvwJb1gILDU
    Accept: application/json
    User-Agent: ZUMO/1.3 (lang=Managed; os=Windows; os_version=6.2.0.9200; arch=Win32NT; version=1.3.21121.0)
    X-ZUMO-VERSION: ZUMO/1.3 (lang=Managed; os=Windows; os_version=6.2.0.9200; arch=Win32NT; version=1.3.21121.0)
    Content-Type: application/json; charset=utf-8
    Host: localhost:51539
    Cookie: ARRAffinity=0289d9a2e779a2431db31b4a154e84828a77f89dbbe1fe391d5fe9794f54f970
    Content-Length: 1237
    Expect: 100-continue
    Accept-Encoding: gzip
    Connection: Keep-Alive

    {
      “access_token”: “eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cdng2OHNrVDgtbVBBQjNCc2VlQSJ9.eyJhdWQiOiJodHRwczovL3JlYWxlc3RhdGVpbnNwZWN0b3IuYXp1cmUtbW9iaWxlLm5ldC9sb2dpbi9hYWQiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9lNjg4ZDU5NC04NjQzLTRiZGYtOWU0Yy0wYmU4YmNiYzY0NWYvIiwiaWF0IjoxNDIyMDkxNjU2LCJuYmYiOjE0MjIwOTE2NTYsImV4cCI6MTQyMjA5NTU1NiwidmVyIjoiMS4wIiwidGlkIjoiZTY4OGQ1OTQtODY0My00YmRmLTllNGMtMGJlOGJjYmM2NDVmIiwiYW1yIjpbInB3ZCJdLCJvaWQiOiJhYmQ3NzkyOC00MWQxLTRjM2MtOGY2Zi0yYTU2ZDg0NGQwNWUiLCJ1cG4iOiJpbnNwZWN0b3JAcmVhbGVzdGF0ZWluc3BlY3Rvci5vbm1pY3Jvc29mdC5jb20iLCJzdWIiOiJnV2RTcEpnYjJpTnJrZnpmYTBUbXhOLVFyM21qajhhcFhfV1lneTdkT3NRIiwibmFtZSI6Ikluc3BlY3RvciIsInVuaXF1ZV9uYW1lIjoiaW5zcGVjdG9yQHJlYWxlc3RhdGVpbnNwZWN0b3Iub25taWNyb3NvZnQuY29tIiwiYXBwaWQiOiJhNWExMGVlOS1mODcxLTRiZGUtOTk3Zi0zZjFjMzIzZmVmYTUiLCJhcHBpZGFjciI6IjAiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJhY3IiOiIxIn0.HTHePADqnWb16e7pa45VJitYSWjojvshL2gr8q4wKY6BJV4_H5phBIfCZwEKFyM92ZPZJskSCVIyBSo6u4y82RRJqlfUoM7xcDmsgGNVSXg8h8hIZnz_VHph8eJxMtogEkGkYYqewDyZ-sZUSiVyrHieiBwd3wc8OHPh4Wxe0mHz8r-zFh8kfciPYoJFBwhg3TaZgxLAbgieLPo7WVAPZHR5yHmTim6ExP8gTz44Zaba27BzHIB5u_hkQvAifSc6nPWqVpp-BjfP3nfmt0j-1zi0oTG1Yo26MC3WHxBMGJljJqX7RhAzuxjvDH1rDnOxOXjWRVMjWh274WR7WkF03A”
    }

    The X-ZUMO-APPLICATION header specified in the request needs to match the MS_ApplicationKey setting specified in the Web.config file. Most of these settings have a default value of “Overridden by portal settings” which, as it implies, is because they are overridden when the Mobile Service is hosted in the cloud. However, when running locally some of these settings need to be specified in order to get authentication to work. In this case it’s both the MS_ApplicationKey and MS_AadTenants:

    <add key=”MS_ApplicationKey” value=”wpxaIplpeXtknXQhqXiVlZAPYQEBcg12″ />
    <add key=”MS_AadTenants” value=”realestateinspector.onmicrosoft.com” />

    With this in place, running the native application again and you can login, retrieve the AAD access token, and then when the mobile service client attempts to login it will do successfully. When you then make a call to one of the controllers, you can set a break point and access the User property to retrieve information about the current user and their claims. This image shows the AAD claim for this user.

     

    image

    Adding WPF Client with Azure Active Directory Authentication and Azure Mobile Service

    Adding WPF Client with Azure Active Directory Authentication and Azure Mobile Service

    In today’s post I was going to cover adding Azure AD authentication to my iOS project but I don’t have my Mac build machine handy so there’s a bit of a change of plans. Today I’m going to add a WPF desktop application to my solution and catch it up to where the other client applications are up to. I’ll start by creating the WPF Application.

    image

    At this point I realised that I missed setting the framework in the Add New Project dialog, so I opened the Properties pane of the application and on the Application tab I set the Target framework to .Net Framework 4.5.

    image

    Next we need to add references to the following solution projects:

    – RealEstateInspector.Core

    – RealEstateInspector.Shared.Client

    And then add reference to both the ADAL and Mobile Service SqliteStore packages. From the downloads page on sqlite.org you’ll also need to download the “32-bit DLL (x86) for SQLite” which is under the Precompiled Binaries for Windows heading. Unblock and Extract the zip file and add the sqlite3.dll file to the new WPF project, setting the Build Action to Content and setting the Copy to Output Directory to Copy always.

    I also need to check the Prefer 32-bit checkbox and define the DESKTOP compilation symbol for All Configurations.

    image

    I’ll add the following XAML markup to the MainWindow.xaml

    <Window x_Class=”RealEstateInspector.Desktop.MainWindow”
            http://schemas.microsoft.com/winfx/2006/xaml/presentation"”>http://schemas.microsoft.com/winfx/2006/xaml/presentation”
            http://schemas.microsoft.com/winfx/2006/xaml"”>http://schemas.microsoft.com/winfx/2006/xaml”
            Title=”MainWindow” Height=”350″ Width=”525″>
        <Grid>
            <Grid.Resources>
                <DataTemplate
                    x_Key=”PropertyItemTemplate”>
                    <TextBlock
                        Text=”{Binding Address}”
                        FontSize=”30″
                        Foreground=”WhiteSmoke” />
                </DataTemplate>
            </Grid.Resources>
            <Grid.RowDefinitions>
                <RowDefinition
                    Height=”Auto” />
                <RowDefinition />
            </Grid.RowDefinitions>
            <Button
                Content=”Authenticate”
                Click=”AuthenticateClick” />
            <ListView
                ItemTemplate=”{StaticResource PropertyItemTemplate}”
                Grid.Row=”1″
                ItemsSource=”{Binding Properties}” />
        </Grid>
    </Window>

    And the following code to the MainWindow.xaml.cs

    public partial class MainWindow : IWin32Window
    {
        public IntPtr Handle
        {
            get
            {
                var interopHelper = new WindowInteropHelper(this);
                return interopHelper.Handle;
            }
        }
        public MainWindow()
        {
            InitializeComponent();

            Loaded += MainWindow_Loaded;
        }
        public MainViewModel CurrentViewModel
        {
            get { return DataContext as MainViewModel; }
        }
        void MainWindow_Loaded(object sender, RoutedEventArgs e)
        {
            var vm = new MainViewModel();
            DataContext = vm;
        }

        private async void AuthenticateClick(object sender, RoutedEventArgs e)
        {
            var token = await AuthenticationHelper.Authenticate(Handle);
            await CurrentViewModel.LoadPropertyData(token);
        }
    }

    I also had to make some minor changes to the AuthenticationHelper

    public static class AuthenticationHelper
    {

        public static async Task<string> Authenticate(
    #if DROID
        Android.App.Activity callerActivity
    #elif DESKTOP
    IntPtr callerHandle
    #endif
            )
        {
            try
            {
                var authContext = new AuthenticationContext(Constants.ADAuthority);
    #if !SILVERLIGHT
                if (authContext.TokenCache.ReadItems().Count() > 0)
                    authContext = new AuthenticationContext(authContext.TokenCache.ReadItems().First().Authority);
    #endif
                var authResult =
                    await
                        authContext.AcquireTokenAsync(Constants.MobileServiceAppIdUri,
                        Constants.ADNativeClientApplicationClientId,
                        new Uri(Constants.ADRedirectUri),
    #if WINDOWS_PHONE_APP || SILVERLIGHT
                        new AuthorizationParameters()
    #elif DROID
                        new AuthorizationParameters(callerActivity)
    #elif DESKTOP
                            new AuthorizationParameters(PromptBehavior.Auto, callerHandle)
    #else
                            new AuthorizationParameters(PromptBehavior.Auto, false)
    #endif
                        );
                Debug.WriteLine(authResult != null);

                return authResult.AccessToken;

            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex.Message);
                return null;
            }
        }
    }

    And that’s it, the WPF desktop application can be run up, the user can sign in and properties are synchronized before being displayed.