Microsoft Build: The future of Xamarin

On the second day of the Microsoft Build conference, during the Keynote, Microsoft had some awesome announcements related to Mobile development. In a following session James Montemagno and Miguel De Icaza got into more detail and even showed more epic new features. As always to two put on a great show while presenting!

Together with my colleague Marco, I’ll cover announcements made at the Microsoft Build conference in a series of blogposts. You can also read these posts on his blog.

Xamarin Live Player
When Xamarin Live Player (XLP) was announced during the Build keynote, most of the audience was pleasantly surprised. Until now developing on Windows for iOS was a serious hassle because it required a Mac to compile the app. This setup works well when you have an expensive Mac and a fast and reliable network, but in a lot of scenarios these builds take up a lot of time.

With XLP you don’t need a Mac build host anymore! You just install the Xamarin Live Player app from the App Store or Play Store, pair your device in Visual Studio and boom! You’re ready to debug on the device. Just select your device (annotated with “Player”) en hit run:

Besides the build improvements XLP has more to offer! You can also modify your Xamarin.Forms or Xamarin.Classic app while debugging so you can easily test changes to your app without stopping and restarting the debug process.
This will really speed up the development! To achieve this you first have to open the view you want to debug live. For now a Xamarin.Forms Xaml and iOS storyboards are supported, when XLP becomes GA all types of views should be supported. After opening your view file, you can run the with Visual Studio by clicking “Run -> Live Run Current View” on Mac or “Tools -> Xamarin Live Player -> Live Run Current View” on Windows.

XLP is still in preview and after some testing we are still experiencing a few difficulties. If you want to give XLP a try, you’re probably best of using the examples provided by James Montemagno.

Fastlane
If you’ve ever developed an app for iOS you probably felt the pain of having to provision your app in the Apple Developer Portal. Although there is a good (and very long) read on how to accomplish this, you don’t want to waste any time on this. This is where Fastlane comes to the rescue. With Fastlane tools installed you are able to provision your app with a few clicks in Visual Studio! Fastlane also comes in handy when releasing your app to the Stores. It handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application.

Xaml standard 1.0
During the Build Conference Microsoft also introduced a new standard for XAML, called XAML Standard 1.0. The standard will describe a specification for cross-platform user interfaces for both UWP and Xamarin.Forms. As for now, XAML Standard is in a very early stage and Microsoft encourages developers to contribute to their specification. 1.0 should become available later this year.

Bindings simplified
Xamarin was already supporting usage of native libraries with Android binding and iOS binding projects. Because of the complex nature of binding projects, Xamarin released the CocoaPods Importer which will simplify importing CocoaPods with a few clicks. With this importer you can easily transform a CocoaPods library to a .NET library.

iOS Extensions
When you’ve created extensions for your app, these extensions will run in a separate process. Therefor the Xamarin runtime was included for every extension. With the latest version of Xamarin, the runtime is only included once for all your extensions. This will result in a smaller app size and improved performance. The latest version of Visual Studio also allows multi-process debugging, that will come in handy when debugging your app combined with your extensions.

AOT for Mac and Android, Hybrid mode
The compilation process of Xamarin.Android and Xamarin.iOS apps was quite different until now. One big difference was that Android was compiled Just In Time, iOS was compiled Ahead Of Time. After the compilation of iOS apps, the LVVM optimizes the generated code to get high performance. Xamarin announced to also start supporting AOT for Android and Mac apps, that will result in better performance. When you compile AOT you might lose some flexibility (for example: no dynamic code loading), and therefor Xamarin also introduced an Hybrid mode. The Hybrid mode will work for platforms that support AOT as well as JIT. It will compile AOT, but also add the bits needed for JIT.

Embedinator-4000

Embedinator-4000​
While the Xamarin platform mostly focuses on writing code in C# and compiling this to a native application, the Embedinator takes a bit of a different approach. The Embedinator makes it possible to write your code in C# and then compile this into a framework library for Java, Swift, Objective-C or C/C++. Therefor you can easily share your C# code with truly native apps. Miguel De Icaza promised that more languages will be added. As for now, the Embedinator can be used from command line, in the future this will be integrated in Visual Studio.

SkiaSharp
SkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Google’s Skia Graphics Library (which is used by apps like Google Chrome). Xamarin announced that it will be supporting Android, iOS, Mac, UWP, tvOS and Windows. Also support for SVG files is added in the latest release. James showed an awesome demo of The Kimono designer which is build on top of SkiaSharp.

Xamarin.IoT
The latest alpha of Xamarin also contains support for Linux based IoT devices! It will add a new project template for Xamarin.IoT and allow you to deploy and debug your IoT app remotely. Debugging will work similar to debugging Xamarin applications. The IoT Hub SDK will make it easy to communicate with your Azure IoT Hub. The library supports communication with MQTT and AMQP message queues.

Mobile Center
Microsoft is putting a lot of effort in making Mobile Center a full fletched CI/CD solution. With the latest release they added support for UWP and the ability to send push notifications to Android or iOS applications. Mobile Center is still in preview, but is expected to become GA later this year.

Project Rome for iOS
Last year Microsoft announced Project Rome SDK for Android. This year at the Build conference Microsoft also announced the iOS SDK. Project Rome creates a bridge between the different platforms for a seamless user experience. The SDK allows developers to start and control apps over platforms and devices.

If you have any comments or want to share your experience, don’t hesitate to contact me on Twitter.

Related links:

 

Microsoft Build: VS4Mac

Last week I travelled to Seattle to attend the Microsoft Build conference. On the first day of the conference there were a lot of cool announcements related to AI, IoT, Azure and more, but Xamarin wasn’t mentioned at all. Slightly related to Xamarin development was the release of Visual Studio for Mac.

Together with my colleague Marco, I’ll cover announcements made at the Microsoft Build conference in a series of blogpost. You can also read these posts on his blog.

In november Microsoft announced the availability of Visual Studio for Mac (VS4Mac) at Microsoft Connect();-event. In the beginning, MonoDevelop was the IDE to develop C# on a Mac, which later converted to Xamarin Studio (XS). But since the Build-conference this week, VS4Mac has gone GA which made it the prime IDE for C# developers on MacOS. Because of this, XS is discontinued and VS4Mac is the way to go. Awesome!

VS4Mac isn’t just a rebrand of XS, is has tons of new features added. When it was Xamarin Studio, you would be able to build apps, games & services for mobile using the technology from Xamarin. Now that it has turned into Visual Studio, you can even make Web and Cloud applications that you can deploy on Microsoft Azure. But that’s not all: VS4Mac also has C# 7.0 support! You’ll now be able to create stuff like Local functions and more of the great stuff C# 7.0 brings us (all running on Mono 5.0).

When creating a Native Mobile App in VS4Mac, you’ll now have the option to add a Mobile Backend, which adds a ASP.NET Core Web API project to the solution as well. You’ll get three different heads in the solution: The .Droid and .iOS projects (for Android and iOS respectively) and a new, .MobileAppService backend.

Visual Studio for Mac

The project template already comes with a small example to show you on how the projects work together. When running the .MobileAppService project, a web server will start on a certain port (in my example: 52599) which will cause Swagger UI to start up. And now the awesome part: VS4Mac supports Multi-process debugging as well! This means that you can debug the .iOS (or .Droid.) project and .MobileAppService project at the same time, jumping back and forth from front-end to back-end code.

By default, the Mobile projects use a MockDataStore that doesn’t make a connection to the .MobileAppService project. Luckily, it’s pretty simple to connect them to eachother and see the multi-process debugging in action. Take the following steps:

  1. Open up the App.cs file in the Shared project
  2. Set the UseMockDataStore boolean to false
  3. Make sure the BackendUrl has the correct port number

Now both the front- & back-end solutions are communicating with eachother, which you can simply prove by setting breakpoints in both solutions and checking the data. Now you’ll be able to create a full solution with a front- and back-end in the same IDE!

Visual Studio for Mac

In the example above you’ll see the ItemsViewModel , a class within the .iOS solution trying to retrieve the data. It jumps to the ItemController, a class within the .MobileAppService project to provide that data back to iOS. Being able to debug across these different threads allows developers to debug solutions quickly.

Other than an ASP.NET Web API, we’re also able to create a website with ASP.NET MVC or Web Forms. Since VS4Mac is running on Roslyn, syntax highlights for HTML and CSS is available. Even the Razor Syntax is supported, making VS4Mac your one-stop shop for Mobile and Web development as well!

Visual Studio for Mac

But it doesn’t stop there – there’s even support for Docker (in Preview) for those that like to play around with Containers. If you’re using Azure Functions to create a Serverless Architecture, you’re covered. If you’re a user of Unity, selecting a *.cs file now automatically opens up VS4Mac as well. With all this functionality already in VS4Mac, it doesn’t matter if you’re using Windows or MacOS!

As far as we know now, it won’t have an exact feature parity with Visual Studio on Windows. Developing UWP on MacOS wouldn’t make much sense as well as developing MacOS apps on Windows doesn’t make sense. But more and more functionality (especially Azure support) will be ported to VS4Mac soon, making it possible to have all the functionality you need to develop C# on MacOS. Go ahead and try it out yourself!

Related links:

Xamarin: UITest backdoor

When running your UI tests, locally or in Xamarin Test Cloud, you sometimes want to execute code in your app from your tests. You might for instance want to setup some mock implementations instead of making actual API calls, or you might want to trigger some OS specific code from your tests. In these scenario’s backdoors come in handy!

Backdoors itself are not very complex, but it opens up a lot of possibilities with UI tests. In the past I used backdoors to:

  • Setup authentication for tests
  • Create a specific state in your app to run your tests in.
  • Set mock implementations from my UI tests.
  • Trigger deeplink

And I can think of a lot more useful scenario’s. You can create a backdoor with the following code:

iOS
In your AppDelegate class you need to create an method that returns NSString, is public,  is annotated with Export attribute and takes an NSString as parameter. For example:

public class AppDelegate : UIApplicationDelegate
{
 [Export("myBackdoorMethod:")] // notice the colon at the end of the method name
 public NSString MyBackdoorMethod(NSString value)
 {
 // In through the backdoor - do some work.
 }
}

Android
On Android you need to create a method in your MainActivity that is public, returns string/void, is annotated with Export attribute and takes an string/int/bool as parameter:

public class MainActivity : Activity
{
    [Export("MyBackdoorMethod")]
    public void MyBackdoorMethod(string value)
    {
        // In through the backdoor - do some work.
    }
}

Invoking the backdoor from your UI tests:

if (app is Xamarin.UITest.iOS.iOSApp)
{
    app.Invoke("myBackdoorMethod:", "exampleString");
}
else
{
    app.Invoke("MyBackdoorMethod", "exampleString");
}

Note: The signature of the backdoor methods is very important as the Backdoors – Xamarin docs mention.

If you want to switch out your actual implementations for mocks, the use of compiler flags (combined with build configurations) might be more suited. You can read more on this over here.

Related links:

Build configurations and compiler flags

If you have developed some Xamarin applications in the past, you might have stumbled on the excessive range of configuration options you can choose from. The settings you’re using in development may be very different from your Release settings. For example; you don’t want to include debug information in the app that will be published to the App Stores. It will increase the app size enormously and expose technical info about your app that might be useful to malicious people.

Besides the difference of Release and Debug configurations, you sometimes need a extra set of configurations. Visual Studio allows you to create additional build configurations:

Configuration Manager
Configuration Manager
Build configurations
Build configurations

Compiler flags / Conditional compilation symbols

Per build configuration you can also specify a set of compiler flags. Compiler flags on itself don’t have any impact on your app, but you can use these flags in your code. By default the build configuration called Debug, has a compiler flag called “Debug”. In your code you can check if this flag is set (and therefor Debug configuration is active) and execute some Debug code. A common scenario is to Log additional information when the Debug flag is set.

Compiler flags
Setting compiler flags

Using compiler flag in code:

#if Debug
	InitializeUiTests();
#endif

Related links:

Xamarin: The magic of Fody weaving

When creating Xamarin apps a lot of people choose to go with the MVVM pattern. There are a lot of beautiful frameworks out there to make the life of an MVVM developer easier, but sometimes you just want to do it the hard way and write it yourself.

If you ever created an Xamarin app using the MVVM pattern (without any framework) and data binding, you may have noticed there is a lot of boilerplate code to notify property changes. As your ViewModels grow, this becomes a nightmare!

Fody.PropertyChanged to the rescue!
Fody is an extensible library that adds an post build task to the MSBuild pipeline. With this task it manipulates the generated IL code, depending on what add-ins you are using. Add-ins can be build on the Fody core. One of the add-ins is Fody.PropertyChanged. As you might guess, this add-in generates the code for notifying changes in a ViewModel. The add-in will look for properties in classes that implement INotifyPropertyChanged or properties/classes annotated with the [ImplementPropertyChanged] attribute.

Example class PersonViewModel:

[ImplementPropertyChanged]
public class PersonViewModel
{
public string GivenNames { get; set; }
public string FamilyName { get; set; }

public string FullName
{
get
{
return string.Format("{0} {1}", GivenNames, FamilyName);
}
}
}

After applying Fody magic it will become:

public class PersonViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;

string givenNames;
public string GivenNames
{
get { return givenNames; }
set
{
if (value != givenNames)
{
givenNames = value;
OnPropertyChanged("GivenNames");
OnPropertyChanged("FullName");
}
}
}

string familyName;
public string FamilyName
{
get { return familyName; }
set
{
if (value != familyName)
{
familyName = value;
OnPropertyChanged("FamilyName");
OnPropertyChanged("FullName");
}
}
}

public string FullName
{
get
{
return string.Format("{0} {1}", GivenNames, FamilyName);
}
}

public virtual void OnPropertyChanged(string propertyName)
{
var propertyChanged = PropertyChanged;
if (propertyChanged != null)
{
propertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
}

Fody.PropertyChanged has another killer feature called Fody NotificationInterception which makes it possible to execute some code before propertyChanged gets triggered. This feature can be for example used for logging purpose or to make sure you are calling propertyChanged on the main thread. See related links for more info.

If you want to give Fody.PropertyChanged (or any other Fody add-in) a try, just install the NuGet package and you’re good to go!

Note:
Fody requires your release builds to contain debug symbols. You can enable this in your project settings by setting Build->compiler->debug information to “Symbols only”.

Fody-release

Related links: