Getting Started with Xamarin.Forms and Presentation Attributes in MvvmCross

Getting Started with Xamarin.Forms and Presentation Attributes in MvvmCross

Previous posts in this sequence on Getting Started with Xamarin.Forms:
Multi-Targeting in Visual Studio, SDK Versions, MvvmCross, Authenticating with ADAL
Refactoring MvvmCross and Services, Effects, Navigation with MvvmCross

The great thing about MvvmCross is that it provides a minimal effort approach to things like navigation. However, there are times when you want to override the navigation model. For example you might want a page to appear as a modal page instead of a regular page. MvvmCross allows you to do this by overriding the default way that a page is presented, which is controlled by a presentation attribute applied to the page. Out of the box, MvvmCross comes with a number of presentation attributes that you can use to control how a page is rendered. By default, if you attempt to navigate to a page, MvvmCross assumes that you just want to navigate to that page using the Xamarin.Forms PushAsync method. This is the same as if you had attributed the page with the MvxContentPagePresentation attribute e.g.

[MvxContentPagePresentation]
public partial class MainPage

Note: By default you do not need to attribute each page with an attribute if you just want to navigate to the page. You can use the MvxContentPagePresentation attribute to override the back stack (i.e. using a combination of the NoHistory and WrapInNavigation properties)

I’m going to change the ProfilePage to appear as a modal page. The only change I need to make is to add the MvxModalPresentation attribute to the ProfilePage class.

[MvxModalPresentation]
public partial class ProfilePage

Now when I run the application the Profile Page will appear as a modal page. Unfortunately there is currently no way to dismiss the modal page, so the application will get stuck with the ProfilePage displayed. To fix this, let’s add a button to the ProfilePage that will be used to close the modal page. Again, I’ll start by showing how to close the page in code behind using the Xamarin.Forms navigation construct:

<Button Text=”Close” Clicked=”CloseClicked”/>


private async void CloseClicked(object sender, System.EventArgs e)
{
    await Navigation.PopModalAsync();
}

Note: Xamarin.Forms distinguishes between closing a modal page using PopModalAsync vs closing a regular page using PopAsync.

Of course, we’d prefer to have the button linked to a command in the view model that can be used to close the corresponding page. The code for the Button and the ProfileViewModel are as follows.

<Button Text=”Close” Command=”{Binding CloseCommand}”/>

public class ProfileViewModel: MvxNavigationViewModel
{
     private IMvxCommand closeCommand;

    public ProfileViewModel(IMvxLogProvider logProvider, IMvxNavigationService navigationService) : base(logProvider, navigationService)
     {
     }

    public IMvxCommand CloseCommand => closeCommand ?? (closeCommand = new MvxAsyncCommand(()=>NavigationService.Close(this)));
}

Note: The ProfileViewModel inherits from the MvxNavigationViewModel so that it can access the NavigationService.

The NavigationService exposes a Close method which will close the current view model, and the corresponding page. This code is the same irrespective of whether the ProfilePage is shown as a regular or a modal page.

There you have it – you can easily override how pages are displayed in your Xamarin.Forms application using presentation attributes in MvvmCross. There are other attributes that come with MvvmCross to allow you easily display pages in master-detail, tabbed and carousel layouts.

image

In addition to the built in attributes, you can override the MvxPagePresentation attribute and add your own custom layout logic for how pages are presented.

Getting Started with Xamarin.Forms and Navigation with MvvmCross

Getting Started with Xamarin.Forms and Navigation with MvvmCross

Previous posts in this sequence:
Getting Started with Xamarin.Forms and Multi-Targeting in Visual Studio
Getting Started with Xamarin.Forms and SDK Versions
Getting Started with Xamarin.Forms with MvvmCross
Getting Started with Xamarin.Forms and Authenticating with ADAL
Getting Started with Xamarin.Forms, Refactoring MvvmCross and Services
Getting Started with Xamarin.Forms and Effects

Xamarin.Forms has a built in mechanism for navigating between pages. Let’s start with navigating from the MainPage to a new ProfilePage, based on the Content Page item template, added to the Pages folder of the UI project.

image

To trigger the navigation, we’ll add a new Button to the MainPage and add logic to navigate to the ProfilePage.

<Button Text=”Profile” Clicked=”ProfileClicked”/>

private async void ProfileClicked(object sender, System.EventArgs e)
{
     await Navigation.PushAsync(new ProfilePage());
}

Navigation between pages includes adding a back button and handles any hardware back button

imageimage

The limitation with the built in navigation model for Xamarin.Forms is that it is triggered in the UI layer (i.e. in the code behind of the MainPage). Using MvvmCross we can move the navigation logic into the domain of the view model, meaning it can be tested independently of the UI.

To do this, we need to add a ProfileViewModel class, which corresponds to the ProfilePage.

image

The ProfileViewModel should inherit from MvxViewModel:

public class ProfileViewModel: MvxViewModel
{
}

The ProfilePage also needs to be updated to inherit from MvxContentPage.

We can now update the MainViewModel to expose a command that can be used to navigate to the ProfileViewModel:

private IMvxCommand profileCommand;
public IMvxCommand ProfileCommand => profileCommand ?? (profileCommand = new MvxAsyncCommand(ShowProfile));
private async Task ShowProfile()
{
     var navService = Mvx.IoCProvider.Resolve<IMvxNavigationService>();
     await navService.Navigate<ProfileViewModel>();

}

The code in the MainPage can now be changed to connect the button to the ProfileCommand in MainViewModel.

<Button Text=”Profile” Command=”{Binding ProfileCommand}”/>

Navigation is now triggered from the ProfileViewModel.

Refactoring to use MvxNavigationViewModel

The code added to the ShowProfile method uses the Mvx IoC container to look up the IMvxNavigationService. This isn’t great as it is a hidden dependency. An alternative would be to add the IMvxNavigationService as a parameter to the MainPage constructor, which would be injected automatically

public MainViewModel(IMvxNavigationService navigationService, ICredentialService credentialService)

Adding the IMvxNavigationService as a parameter in the constructor means that the view model has to maintain a reference to it until it’s used by the ShowProfile method. Alternatively, we can change the base class to use the MvxNavigationViewModel which already exposes a NavigationService property.

public MainViewModel(IMvxLogProvider logProvider, IMvxNavigationService navigationService, ICredentialService credentialService) : base(logProvider, navigationService)

and the updated ShowProfile method is:

private async Task ShowProfile()
{
     await NavigationService.Navigate<ProfileViewModel>();
}

Navigation using MvvmCross provides a nice abstraction away from the UI layer. It can also be customised to display master-detail, tabbed and other page types.

Getting Started with Xamarin.Forms and Effects

Getting Started with Xamarin.Forms and Effects

Previous posts in this sequence:
Getting Started with Xamarin.Forms and Multi-Targeting in Visual Studio
Getting Started with Xamarin.Forms and SDK Versions
Getting Started with Xamarin.Forms with MvvmCross
Getting Started with Xamarin.Forms and Authenticating with ADAL
Getting Started with Xamarin.Forms, Refactoring MvvmCross and Services

At some point in building a cross platform application using Xamarin.Forms you’ll need to build out some platform specific features. There are a couple of ways to do this, depending on what you want to achieve. One of those ways is to use an Effect. In this example we’re going to create an Effect that can be used to add a tooltip to any element. For the purposes of this exercise we’re going to assume that this only makes sense to add on UWP where the application can be used on a desktop where the user has a mouse and keyboard attached.

An Effect has two parts:

– A platform agnostic class which will contain any properties that the Effect needs to expose in XAML. This is the name of the element that will appear in XAML. In this case the class will be called TooltipEffect and inherits from RoutingEffect

– A platform specific class which provides the platform specific implementation. In this case this class will be called TooltipPlatformEffect and inherits from PlatformEffect. Note that as this is platform specific, it needs to reside in the platform specific folder

As an Effect is a UI component, it should be added to the UI project, which should now look something like:

image

A couple of things to note here:

– There are folders for Converters, Effects and Renderers – I’ve added these as they are common elements that you’ll be adding to your UI project

– I’ve moved MainPage into a folder called Pages

– In a lot of cases I’ll have another folder called Controls, which will contain any custom or user controls I build.

– The TooltipEffect class sits in the Effects folder (platform agnostic)

– The TooltipEffect.Platform file, which contains the TooltipPlatformEffect class, sits in the Uap platform specific folder

Now, let’s look at the implementation of the effect. First, we’ll start with the TooltipEffect:

public class TooltipEffect : RoutingEffect
{
     public TooltipEffect() : base(“StrataPark.TooltipEffect“)
     {
     }


    public string Tooltip { get; set; }
}

This class exposes a Tooltip string property which will be used to specify the tooltip text in XAML. In the call to the base constructor it passes in a unique identifier for the Effect. This is important to note because it needs to align with the identifier used by the platform specific implementation. Speaking of which, here’s the TooltipPlatformEffect:

[assembly: ResolutionGroupName(“StrataPark”)]
[assembly: ExportEffect(typeof(TooltipPlatformEffect), nameof(TooltipEffect))]


namespace StrataPark.UI.Effects
{
     [Preserve]
     public class TooltipPlatformEffect : PlatformEffect
     {
         protected override void OnAttached()
         {
             var view = Control ?? Container;


            var effect = Element.Effects.OfType<TooltipEffect>().FirstOrDefault();
             if (!string.IsNullOrWhiteSpace(effect?.Tooltip) && view != null)
             {
                 var toolTip = new ToolTip
                 {
                     Content = effect?.Tooltip
                 };
                 ToolTipService.SetToolTip(view, toolTip);
             }
         }


        protected override void OnDetached()
         {
         }
     }
}

The most important part of this code are the assembly level attributes that register both the namespace (i.e. the StrataPark prefix) and the element identifier (nameof(TooltipEffect) gives the second part of the identifier, “ToolTipEffect”). If the combination of these attributes don’t yield the same identifier set in the platform agnostic Effect, the platform specific implementation won’t be loaded at runtime.

You can now use this Effect in XAML as follows

<Button Text=”Authenticate” Command=”{Binding AuthenticateCommand}”>
     <Button.Effects>
         <effects:TooltipEffect Tooltip=”Welcome tooltip”/>
    </Button.Effects>
</Button>

One last note – when adding folders to your project, you should keep an eye on the changes that take place in your csproj. When you add/remove files and folders, occasionally Visual Studio will add unnecessary items to the csproj. Remember that by default files and folders will be include in the new csproj format. So for example, the following xml is not required, and should be removed, prior to checking your code in:

<ItemGroup>
   <Folder Include=”Converters” />
   <Folder Include=”Renderers” />
</ItemGroup>

As you’ve seen, Effects are one way to add platform specific UI logic to your application. An alternative, is to use Renderers but that’s a topic for another post.

Debugging Not Working for .NET Standard library in UWP Application

Debugging Not Working for .NET Standard library in UWP Application

I was attempting to debug some code in a .NET Standard library that was being referenced from a Xamarin.Forms base UWP application. Unfortunately, it didn’t matter where I set the breakpoint in the library, they were never hit. Initially I thought that this was related to it being a multi-targeted project but it turns out this same issue applies to a regular .NET Standard library.

The only hint I had was when the application was running there was a yellow warning triangle on my breakpoint which a pretty unhelpful, yet accurate, message.

image

Now you’d have thought that since this project was included in the same solution as the application, that it was being built by Visual Studio as part of building and running the application, that you wouldn’t have to do anything special to get step through debugging to work. This is not the case – it appears that debug symbols can’t be loaded – huh! I mean seriously, we expect better.

I had also recently installed the first preview of Visual Studio 2017 15.9 so I thought that might be the issue but no, even opening it in 15.8 still showed the same issue.

So it turns out that there is an issue with the default build configuration – open project properties for the .NET Standard library and click on Advanced under the Build tab

image

The default “Debugging information” value of Portable is what the issue is. Change this to Full or Pdb-only

image

Doing this will set the debugging settings for the currently selected target framework and platform. For example for my project it generated:

<PropertyGroup Condition=”‘$(Configuration)|$(TargetFramework)|$(Platform)’==’Debug|netstandard2.0|AnyCPU'”>
   <DebugType>pdbonly</DebugType>
   <DebugSymbols>true</DebugSymbols>
</PropertyGroup>

I simplified this so that it would always use these debugging settings when doing a Debug build

<PropertyGroup Condition=”‘$(Configuration)’==’Debug'”>
   <DebugType>pdbonly</DebugType>
   <DebugSymbols>true</DebugSymbols>
</PropertyGroup>

And there you have it – step through debugging should now work. I’m not sure why it’s so hard for Visual Studio to either use this option by default, or at least provide a useful warning that directs the developer to either documentation, or actually switches the setting automatically.

Getting Started with Xamarin.Forms, Refactoring MvvmCross and Services

Getting Started with Xamarin.Forms, Refactoring MvvmCross and Services

Previous posts in this sequence:
Getting Started with Xamarin.Forms and Multi-Targeting in Visual Studio
Getting Started with Xamarin.Forms and SDK Versions
Getting Started with Xamarin.Forms with MvvmCross
Getting Started with Xamarin.Forms and Authenticating with ADAL

In this post I’m going to do a bit of a refactor based on the work completed in the previous post where we added code directly into the MainViewModel to use the Azure Active Directory Authentication Library. This would be fine if the MainViewModel was the only view model in the application that needed access to the Authenticate method. As I will probably want to make use of it elsewhere, I’ve decided to refactor that code into a class called CredentialService.

When I wired up MvvmCross a couple of posts ago, I did so without going into much detail on how the relationship between view models and their corresponding page is setup. I’m not going to delve into the inner workings of MvvmCross but suffice to say that there is some reflection magic that goes on based on the names of the classes. A view model with the name MainViewModel will be paired with a page called MainPage.

In addition to the magic that glues the view model and pages together (and thus the navigation model) MvvmCross also has a quite powerful dependency injection framework. The CredentialService that I’ll be creating will be registered with the DI framework as a singleton that can be easily accessed.

Let’s start by creating the CredentialService and it’s corresponding interface ICredentialService in a folder called Services in the Core library.

public partial class CredentialService:ICredentialService
{
     private const string AuthEndpoint = “
https://login.microsoftonline.com/{0}/oauth2/token”;


    private const string ResourceId = “https://graph.windows.net/”;
     private const string TenantId = “[your tenantId]”;
     private const string ClientId = “[your clientId]”;
     private const string RedirectURI = “[your redirectURI]”;


    public string AccessToken { get; set; }


    public async Task<string> Authenticate()
     {
         string authority = string.Format(CultureInfo.InvariantCulture, AuthEndpoint, TenantId);
         var authContext = new AuthenticationContext(authority);


        var result = await authContext.AcquireTokenAsync(ResourceId, ClientId, new Uri(RedirectURI), this.PlatformParameters);
         AccessToken = result.AccessToken;
         return AccessToken;
     }
}

public interface ICredentialService
{
     Task<string> Authenticate();
}

The platform specific code will need to be extracted out of the MainViewModel.Platform.cs into the corresponding CredentialService.Platform.cs. For example the UWP class would be:

public partial class CredentialService
{
     private IPlatformParameters PlatformParameters => new PlatformParameters(PromptBehavior.Always, false);
}

In order to register the CredentialService with the DI framework, we just need to add a small bit of code to the Initialize method of the App class in the Core library

public override void Initialize()
{
     CreatableTypes()
         .EndingWith(“Service”)
         .AsInterfaces()
         .RegisterAsLazySingleton();


    RegisterAppStart<MainViewModel>();
}

The last step is to make use of the service in the MainViewModel. We do this by adding a parameter of type ICredentialService to the MainViewModel constructor.

private ICredentialService CredentialService { get; }
public MainViewModel(ICredentialService credentialService)
{
     CredentialService = credentialService;
}


private async Task Authenticate()
{
     Debug.WriteLine(await CredentialService.Authenticate());
}

And that’s it – we haven’t changed any functionality but the solution is better organised and structured in a way that services can easily be added without cluttering up view models.

image

Where’s the Latest Android Emulator?

Where’s the Latest Android Emulator?

I’ve been struggling to get the Android emulator to perform at a level where debugging was possible. After upgrading to VS15.8 I was able to switch over to use the new Windows Hypervisor support (note that “Windows Hypervisor Platform” is different from the Hyper-V feature in the Windows Features dialog). However, I found that the performance of the emulator was so bad that debugging was barely possible – infinitely worse than when I was using the HAXM support.

After spending a bit of time searching online I came across references to versions of the Android emulator that were higher than what I was using. I double-checked the Android SDK Manager just in case there were updates available but there were none.

Eventually I realised that by selecting the cog in the lower right corner of the SDK Manager I was able to switch from the Microsoft repository across to the Google repository.

image

After switching to the Google repository there was indeed an update to the tools, which included the new emulator version.

Did this fix the performance issue? Not entirely. Performance was better in the Android P emulator but still nowhere near as good as a real device (even an old one).

If all else fails, go to the source. I reached out to Miguel and asked if this was a known issue.

image

Looks like we need to wait for a Windows update in order to get this performance fix.

Getting Started with Xamarin.Forms and Authenticating with ADAL

Getting Started with Xamarin.Forms and Authenticating with ADAL

Previous posts in this sequence:
Getting Started with Xamarin.Forms and Multi-Targeting in Visual Studio
Getting Started with Xamarin.Forms and SDK Versions
Getting Started with Xamarin.Forms with MvvmCross

Now that we’ve got the basics of an application, we’re going to add some authentication using the Azure Active Directory Authentication Library. We’re going to start with registering an application with Azure Active Directory (AAD) (the docs do cover this here but I figured I’d cover it again anyway). Start by heading over to the Azure portal and selecting Azure Active Directory from the set of tabs on the left.

image

In the list of tabs for the AAD, find the App Registrations tab

image

Click “New application registration” and fill in the details for the new app

image

Note that the Sign-on URL doesn’t have to be a real URL, just one that both the portal and the app know about – we’ll use this later! After you’re done creating the app registration you should be able to retrieve the Application ID. Save this information for later as we’ll need it when we’re authenticating the user within our application.

image

The pieces of information you’ll need in order to use ADAL within your application are:

clientId – This is the Application ID that was displayed after you created the app registration in the Azure portal. This is a GUID

redirectUri – This is the Redirect URI that you specified when creating the app registration. If you didn’t write this down, or you want to double check, or change it, you can do so by clicking the Redirect URIs tab under Settings for the app registration. This is a URL (e.g. https://stratapark)

resourceId – This is the identifier of the resource you want to access. In this case we just want to authenticate the user, so we’re going to use the default resource, which is the AAD directory itself, https://graph.windows.net/. This can be a URL or a GUID depending on the type of resource you’re referencing

tenantId – This is the identifier of the tenant that you’re authenticating against. This can be the URL or GUID of your tenant.

To retrieve the tenantId you need to select the Properties tab of the Azure Active Directory and copy the Directory ID

imagehttps://www.nuget.org/packages/Microsoft.IdentityModel.Clients.ActiveDirectory/

Now that we’ve setup the app registration, we’re good to start writing some code. Firstly, we need to add a reference to the ADAL library from NuGet – search for Microsoft.IdentityModel.Clients.ActiveDirectory

image

Add the ADAL library to all projects.

Let’s start with the UI and add a button to the MainPage.

<Button Text=”Authenticate” Command=”{Binding AuthenticateCommand}” />

And of course we need a command within the MainViewModel. In fact we’ll add the bulk of the authentication code to the MainViewModel too:

private IMvxCommand authenticateCommand;
public IMvxCommand AuthenticateCommand => authenticateCommand ?? (authenticateCommand = new MvxAsyncCommand(Authenticate));


private const string AuthEndpoint = “https://login.microsoftonline.com/{0}/oauth2/token”;


private const string ResourceId= “https://graph.windows.net/”;

private const string TenantId = “[your tenantId]”;
private const string ClientId = “[your clientId]”;
private const string RedirectURI = “[your redirectUri]”;


public async Task Authenticate()
{
     string authority = string.Format(CultureInfo.InvariantCulture, AuthEndpoint, TenantId);
     var authContext = new AuthenticationContext(authority);


    var result = await authContext.AcquireTokenAsync(ResourceId, ClientId, new Uri(RedirectURI), PlatformParameters);
     Debug.WriteLine( result.AccessToken);
}

The only thing missing is the PlatformParameters (bolded in the code above). As the name suggests, these are platform specific parameters required by the ADAL library. For each platform we need to expose a property that returns an IPlatformParameters within the MainViewModel.Platform.cs for each platform.

Android

private IPlatformParameters PlatformParameters => new PlatformParameters(CurrentActivity, true, PromptBehavior.Auto);
public Activity CurrentActivity
{
     get
     {
         var top = Mvx.IoCProvider.Resolve<IMvxAndroidCurrentTopActivity>();
         return top.Activity;
     }
}

iOS

private IPlatformParameters PlatformParameters => new PlatformParameters(GetTopViewController(),true, PromptBehavior.Auto);
public static UIViewController GetTopViewController()
{
     var window = UIApplication.SharedApplication.KeyWindow;
     var vc = window.RootViewController;
     while (vc.PresentedViewController != null)
         vc = vc.PresentedViewController;


    if (vc is UINavigationController navController)
         vc = navController.ViewControllers.Last();


    return vc;
}

UAP

private IPlatformParameters PlatformParameters => new PlatformParameters(PromptBehavior.Always, false);

NetStandard

private IPlatformParameters PlatformParameters => null;

Note: you need to provide the NetStandard implementation otherwise the NetStandard target won’t build.

There is one more thing we need to add. Android requires an additional piece of code within the Activity that hosts the Xamarin.Forms application

protected override void OnActivityResult(int requestCode, Result resultCode, Intent data)
{
     base.OnActivityResult(requestCode, resultCode, data);
     AuthenticationAgentContinuationHelper.SetAuthenticationAgentContinuationEventArgs(requestCode, resultCode, data);
}

If your Android application authenticates but doesn’t ever return the access token, chances are that your OnActivityResult override is either missing, or on the wrong Activity – I spent a bit of time trying to work out why iOS and UWP worked but Android would just hang; turns out I was missing this override.

There you have it – you’re good to go with using ADAL to authenticate your users within your Xamarin.Forms application

Getting Started with Xamarin.Forms with MvvmCross

Getting Started with Xamarin.Forms with MvvmCross

Previous posts in this sequence:

Getting Started with Xamarin.Forms and Multi-Targeting in Visual Studio

Getting Started with Xamarin.Forms and SDK Versions

Next up is adding in MvvmCross – no surprises here: Add the MvvmCross package to all projects in the solution

image

We need to make a few adjustments to the Core library. First up, we need to add an App class to Core that inherits from MvxApplication. For the moment the only thing this class is going to do is to set the initial view model of the application. One of the core ideas behind MvvmCross is that navigation is driven from view models, rather than at the view level. By setting the initial view model, we’re effectively defining which view will be shown when our application launches.

public class App : MvxApplication
{
     public override void Initialize()
     {
         RegisterAppStart<MainViewModel>();
     }
}

We’ll do a bit of tidying up whilst we’re making changes to the Core project. We’ll create a ViewModels folder and move MainViewModel into folder

We’ll update MainViewModel and MainViewModel.Platform.cs (all four) to add ViewModels to namespace. We’ll also update MainViewModel to inherit from MvxViewModel.

Now that we’ve updated the Core library, we’ll turn our attention to the UI library and the head projects. We’ll add the MvvmCross.Forms NuGet reference to all projects, except Core.

image

The only other change we need to make to the UI library for the moment is to update MainPage to inherit from MvxContentPage instead of ContentPage. You’ll need to do this in both the xaml and xaml.cs files. However, I would recommend dropping the inheritance from the xaml.cs file as it is not required in multiple places.

Next up we need to adjust each of the head projects (UWP, iOS and Android) so that they use MvvmCross to launch the Xamarin.Forms views.

UWP

Rename MainPage to HostPage (in both MainPage.xaml and MainPage.xaml.cs, and the filenames themselves) in the UWP head project – we do this to avoid any confusion between the name of the page and any views that are automatically associated with MainViewModel. Also update HostPage to inherit from MvxFormsWindowsPage.

For UWP we need an additional step due to some limitation around the support for generics. Add a help class ProxyMvxApplication, defined as follows:

public abstract class ProxyMvxApplication : MvxWindowsApplication<MvxFormsWindowsSetup<Core.App, UI.App>, Core.App, UI.App> { }

Change App.xaml and App.xaml.cs to inherit from ProxyMvxApplication, and remove all code in App.xaml.cs other than the constructor which should contain a single call to InitializeComponent. Override the HostWindowsPageType method in the App class

protected override Type HostWindowsPageType()
{
     return typeof(HostPage);
}

Build and run the UWP application

iOS

Update the AppDelegate as follows

public partial class AppDelegate : MvxFormsApplicationDelegate<MvxFormsIosSetup<Core.App, UI.App>, Core.App, UI.App>
{ }

Build and run the iOS application.

Android

Rename and update the MainActivity as follows. Again, we rename the activity to avoid confusion with any activity or view that would be automatically associated with MainViewModel.

public class HostActivity
         : MvxFormsAppCompatActivity<MvxFormsAndroidSetup<Core.App, UI.App>, Core.App, UI.App>
{ }

Build and run the Android application.

You may experience a build error when you attempt to build and run the Android application, relating to referencing the Mono.Android.Export library. In this case, use the Add Reference dialog to manually add the missing reference.

image

There you have it – all three platforms running Xamarin.Forms application powered by MvvmCross.

Getting Started with Xamarin.Forms and SDK Versions

Getting Started with Xamarin.Forms and SDK Versions

In my previous post I did a walk through of creating a new Xamarin.Forms application and setting up the Core and UI projects for multi-targeting. Whilst I covered updating the various NuGet packages, I didn’t look at the SDK versions for the three platforms. In this post I’m going to look at the options for setting the SDK version, as it’s important that you update this to target the latest SDK version, even if your application is going to support older platform versions.

Android

If you right-click on the Android head project and select Properties you’ll see the Project Properties pane.

Start by increasing the Target Framework by selecting the highest Android version that you have installed

image

Next, on the Android Manifest tab, select “Use Compile using SDK version” under the Target Android version. On this tab you can also set the Minimum Android version if you don’t want to accept the defaults – this may be relevant if you don’t want a massive support matrix for your application as it will prevent installation on devices running a version of Android older than the minimum.

image

Build and run the Android application to make sure you haven’t broken anything and then commit your changes – in this case the first change would have made changes to the Android csproj file, whereas the second change would have changed the AndroidManifest.xml file.

iOS

Setting the SDK Version for iOS is straight forward and the recommendation is to leave the “Default” (which should be the default value) in the SDK Version dropdown on the iOS Build tab on the Properties pane for the iOS application.

image

If you want to adjust the minimum supported version of iOS, you can do this by double-clicking the Info.plist file for your iOS application and then adjusting the Deployment Target.

image

UWP

Both the Target and Min version of the UWP application can be set from the Application tab of the Project Properties pane. Setting the Target version defines the SDK version that will be used to compile the application and thus the APIs that are available.

image


Core and UI

Now that the Core and UI libraries are set to be multi-targeted it is also necessary to define what the target framework/version should be for each platform. If you don’t do this, you may be limited as to what platform APIs are available. Rather than setting these values in each of the libraries, we can create a file, Directory.build.targets, in the solution folder and include the appropriate elements there – this will get included in all projects that support the new csproj format. In this case the contents of our Directory.build.targets file will look like

<Project>
   <PropertyGroup Condition=”$(TargetFramework.StartsWith(‘netstandard’))”>
     <DefineConstants>$(DefineConstants);NETSTANDARD;PORTABLE</DefineConstants>
   </PropertyGroup>
   <PropertyGroup Condition=”$(TargetFramework.StartsWith(‘uap’))”>
     <DefineConstants>$(DefineConstants);NETFX_CORE;XAML;WINDOWS;WINDOWS_UWP</DefineConstants>
     <TargetPlatformVersion>10.0.17134.0</TargetPlatformVersion>
     <TargetPlatformMinVersion>10.0.16299.0</TargetPlatformMinVersion>
   </PropertyGroup>
   <PropertyGroup Condition=”$(TargetFramework.StartsWith(‘Xamarin.iOS’))”>
     <DefineConstants>$(DefineConstants);MONO;UIKIT;COCOA;IOS</DefineConstants>
   </PropertyGroup>
   <PropertyGroup Condition=”$(TargetFramework.StartsWith(‘MonoAndroid’))”>
     <DefineConstants>$(DefineConstants);MONO;ANDROID</DefineConstants>
   </PropertyGroup>
</Project>

The csproj for both Core and UI projects also needs to be updated to replace the target framework MonoAndroid81 with MonoAndroid90.

All your projects should now be targeting the latest framework/sdk versions. If you find that some, or all, of these changes don’t take effect, you may need to either reload specific projects, or restart Visual Studio.

Getting Started with Xamarin.Forms and Multi-Targeting in Visual Studio

Getting Started with Xamarin.Forms and Multi-Targeting in Visual Studio

I’ve walked through this a couple of times in the past (last year and in the Mvx+1 series I started) but I wanted to do an updated post to firstly point out that the getting started process in Visual Studio has stabilized quite a lot and the process of getting a new Xamarin.Forms project up and running is quite smooth. The second thing I wanted to add is how, and why, you can setup your .NET Standard libraries to be multi-targeted – this also has come a long way.

Note: I’m running Visual Studio 15.8 preview 5, so your experience may vary a little if you’re running a different version of Visual Studio. Before I get started I try to make sure all my components are up to date, including my MacMini which is what I use for building/debugging iOS applications.

Let’s get started by creating a new solution within Visual Studio, using the Mobile App (Xamarin.Forms) project template

image

This will prompt you to select what template to use, in this case we’re going to create a project based on a Blank template. In actual fact this template isn’t blank; it has 1 page which is required in order for the application to build and run. Also, make sure you select the .NET Standard Code Sharing Strategy. DO NOT select Shard Project – this options in my opinion should now be deprecated as multi-targeting is a much better option for achieving this same outcome.

image

After clicking OK to create the project, you’ll want to make sure you can successfully build all projects.

Next open the NuGet package manager for the solution and update all packages to the latest stable. In my case I just had to update Microsoft.NETCore.UniversalWindowsPlatform and Xamarin.Forms.

Now, make sure that each platform (i.e. iOS, Android and UWP) compiles and runs. Technically you don’t need to do this but if you run into difficulty later, at least doing a run check here gives you a “last known good” state to revert to. On that note, after checking that each platform runs, I would be making the initial commit to source control for your solution.

Next we’re going to add a new project based on the Class Library (.NET Standard) project template. This will be our Core project that will contain all our view models, services and business logic for the application.

image

The new project will come with Class1. Rename both the file and class name to MainViewModel.

Next we’re going to do a bit of a tidy up. By default the project that contains the XAML for the application (i.e. App.xaml) and for the main page of the application (MainPage.xaml) was given the same name as the solution itself. I’m not a big fan of that so I rename this to have the UI suffix. To do this you need to remove the existing project, rename the folder and project name, and add the existing project back into the solution. Don’t forget that you’ll need to update the namespace for both App and MainPage classes (in both XAML and code behind files) to include UI (e.g. the full type name of the MainPage class should be StrataPark.UI.MainPage)

After renaming the UI project, we need to double check that all the projects have the correct references. The only project reference the UI project should have is to the Core project

image

All three of the head projects (i.e. for iOS, Android and UWP) should reference both the Core and UI projects

image

Now’s another time to check that everything builds and runs (all three platforms) and then commit your changes!

Both the Core and UI projects are currently just .NET Standard 2.0 projects. This means that all code is the same for all platforms. By making these projects multi-targeted, we can enable platform specific code to be included where necessary. This is similar to the way shared libraries used to work. However, the difference is that the code stays in a separate assembly, away from the head projects.

To make use of multi-targeting, first create a file called global.json in solution folder, with the following contents:

{
     "msbuild-sdks": {
         "MSBuild.Sdk.Extras": "1.6.47"
     }
}

The MSBuild.Sdk.Extras package extends the raw multi-targeting support provided by Visual Studio/MSBuild. For both Core and UI projects, edit the csproj and replace the default TargetFramework element at the beginning of the file with the following (make sure you include the Project element as this sets the Sdk to use)

<Project Sdk="MSBuild.Sdk.Extras">
   <PropertyGroup>    <TargetFrameworks>netstandard2.0;Xamarin.iOS10;MonoAndroid81;uap10.0.16299</TargetFrameworks>
   </PropertyGroup>

   <ItemGroup>
     <Compile Remove="Platforms\**\*.cs" />
     <None Include="Platforms\**\*.cs" />
   </ItemGroup>
   
   <ItemGroup Condition=" $(TargetFramework.StartsWith('netstandard')) ">
     <Compile Include="Platforms\Netstandard\**\*.cs" />
   </ItemGroup>
   
   <ItemGroup Condition=" $(TargetFramework.StartsWith('uap')) ">
     <Compile Include="Platforms\Uap\**\*.cs" />
   </ItemGroup>

   <ItemGroup Condition=" $(TargetFramework.StartsWith('Xamarin.iOS')) ">
     <Compile Include="Platforms\Ios\**\*.cs" />
   </ItemGroup>

   <ItemGroup Condition=" $(TargetFramework.StartsWith('MonoAndroid')) ">
     <Compile Include="Platforms\Android\**\*.cs" />
   </ItemGroup>

If you take a look at the code that was added to the csproj, you can see that there are some conditional inclusions based on the target platform. We’ll make use of this to return a platform specific welcome text for our application.

Add a Platforms folder to the Core project

Add Netstandard, Ios, Android and Uap sub-folders to the Platforms folder

Add a file called MainViewModel.Platform.cs to each sub-folder of the Platforms folder with the following text. Replace Netstandard with the name of the platform (i.e. the sub-folder name)

public partial class MainViewModel
{
     private string PlatformWelcomeText => "Welcome from Netstandard";
}

Next, we’ll modify the MainViewModel.cs file. Note how the WelcomeText property returns the platform specific text

public partial class MainViewModel
{
    public string WelcomeText => PlatformWelcomeText;
}

In the MainPage.xaml, add a new Label element that is bound to the WelcomeText property

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

In the codebehind for the MainPage.xaml, add the following code to the end of the MainPage constructor

BindingContext = new MainViewModel();

Now when we build and run the application on each platform, we’ll see a platform specific welcome.

image

This technique can be used to include all sorts of platform specific code within your application, making it easier to deal with the Mvvm abstraction when you need to tie into platform specific APIs. In the past you’d have typically had to create a service in the head project, or some other clumsy workaround.

Functionality and Usability beats Visual Design and Animations any day of the week!

Functionality and Usability beats Visual Design and Animations any day of the week!

Since Windows 10 was released I’ve periodically opened and attempted to use the Mail and Calendar applications that come preinstalled and in theory provide an integrated experience. As far as UWP applications go, there aren’t many that I look to as great showcases of what the platform is capable of but I figured that Microsoft would invest in their first party applications (there’s also Maps and a few others). It’s taken a few iterations but both Mail and Calendar are actually working quite well – they both support multi-window (although it’s a tad annoying that you can’t tell it to open items in a new window by default), and the UI generally has a lot of polish. However, that’s pretty much where the fairy tale ends.

The reality is that the Mail and Calendar applications are separate applications, and thus when you attempt to do things like “create a meeting from an email”, something that’s a simple drag and drop in Outlook, you are completely out of luck. Further more, despite quite a lot of effort having gone into the visual design, I still find that I’m struggling with basic things like scanning my email and seeing which items are read/unread and which ones I should be focussing on.

I know that these applications aren’t designed as a complete substitute for Outlook but I do wonder who makes the decisions on where the investment in these products is spent. Is there no focus on productivity, or is it just a competition to have the best looking design?

Speed up development with Multi-Targeted Visual Studio Projects

Speed up development with Multi-Targeted Visual Studio Projects

One of the biggest changes that MvvmCross undertook at the beginning of the year was to switch over to using Multi-targeting in Visual Studio. Instead of having a lot of platform specific projects, multi-targeting made it possible to create a single MvvmCross project that had multiple target frameworks. MvvmCross leverages Oren’s MSBuild.Sdk.Extras nuget package which allows us to define the list of target frameworks using the TargetFrameworks element in the csproj file (note that this is different from the default singular TargetFramework element which usually exists).

<TargetFrameworks>netstandard2.0;net461;Xamarin.iOS10;Xamarin.Mac20;Xamarin.TVOS10;Xamarin.WatchOS10;MonoAndroid81;tizen40;netcoreapp2.0;uap10.0.16299</TargetFrameworks>

Now, instead of ~220 projects, the MvvmCross.sln now has 57 projects. However, this transition comes at a cost. Firstly, defining all the target frameworks like this will mean that it won’t compile on Mac because UWP doesn’t exist there. MvvmCross addressed this by including some conditional logic to detect whether the solution was being built on Windows or not.

<TargetFrameworks Condition=” ‘$(OS)’ == ‘Windows_NT’ “> netstandard2.0;net461;Xamarin.iOS10;Xamarin.Mac20;Xamarin.TVOS10;Xamarin.WatchOS10;MonoAndroid81;tizen40;netcoreapp2.0;uap10.0.16299</TargetFrameworks>
<TargetFrameworks Condition=” ‘$(OS)’ != ‘Windows_NT’ “> netstandard2.0;net461;Xamarin.iOS10;Xamarin.Mac20;Xamarin.TVOS10;Xamarin.WatchOS10;MonoAndroid81;tizen40;netcoreapp2.0</TargetFrameworks>

The second problem is that building the solution became incredibly slow. Every change to the core MvvmCross project meant it had to be recompiled for each target framework. Luckily this doesn’t impact developers using MvvmCross, but it does mean that making changes to MvvmCross is a painful process. This is made worse by the weak support within Visual Studio for multi-targeting, often resulting in having to clean bin/obj folders, restarting VS etc.

Most of the time when working on a feature or a bug in MvvmCross we’ll be targeting one platform; at least until we have it working, and then we’ll test on the other platforms. It would be really nice if Visual Studio supported this workflow, allowing us to effectively disable compilation of the platforms we’re not interested in.

Recently we made a change to the MvvmCross projects to add further conditional logic:

<PropertyGroup Condition=” ‘$(TargetsToBuild)’ == ‘All’ “>
   <TargetFrameworks Condition=” ‘$(OS)’ == ‘Windows_NT’ “>netstandard2.0;net461;Xamarin.iOS10;Xamarin.Mac20;Xamarin.TVOS10;Xamarin.WatchOS10;MonoAndroid81;tizen40;netcoreapp2.0;uap10.0.16299</TargetFrameworks>
   <TargetFrameworks Condition=” ‘$(OS)’ != ‘Windows_NT’ “>netstandard2.0;net461;Xamarin.iOS10;Xamarin.Mac20;Xamarin.TVOS10;Xamarin.WatchOS10;MonoAndroid81;tizen40;netcoreapp2.0</TargetFrameworks>
</PropertyGroup>


<PropertyGroup Condition=” ‘$(TargetsToBuild)’ != ‘All’ “>
   <TargetFrameworks Condition=” ‘$(TargetsToBuild)’ == ‘Android’ “>netstandard2.0;MonoAndroid81;</TargetFrameworks>
   <TargetFrameworks Condition=” ‘$(TargetsToBuild)’ == ‘Uap’ “>netstandard2.0;uap10.0.16299</TargetFrameworks>
   <TargetFrameworks Condition=” ‘$(TargetsToBuild)’ == ‘iOS’ “>netstandard2.0;Xamarin.iOS10</TargetFrameworks>
</PropertyGroup>

As you can see, this inspects the variable TargetsToBuild in order to determine what target platforms to build. This variable is defined in the Directory.build.props so that it can be referenced from any of the MvvmCross projects.

<PropertyGroup Condition=” ‘$(Configuration)’ == ‘Debug’ “>
   <!– <TargetsToBuild>All</TargetsToBuild>  –>
   <!–<TargetsToBuild>Android</TargetsToBuild>–>
   <TargetsToBuild>Uap</TargetsToBuild>
   <!–<TargetsToBuild>iOS</TargetsToBuild>–>
</PropertyGroup>


<PropertyGroup Condition=” ‘$(Configuration)’ != ‘Debug’ “>
   <TargetsToBuild>All</TargetsToBuild>
</PropertyGroup>

To make sure that this option doesn’t affect Release builds (ie creation of nuget packages) if the Configuration isn’t set to Debug, TargetsToBuild is set to All. In the above code, the TargetsToBuild variable is set to Uap. This means that only the Uap (and netstandard) targets will be built – this is a massive performance gain when debugging.

Note: If you change the TargetsToBuild property you will most likely have to restart Visual Studio and/or force a rebuild of the entire solution but the performance gain you get out of using the TargetsToBuild variable is well worth it.