2 Ways to Run Surface Duo Emulator

Microsoft announced they will be releasing the new Surface Duo in December of 2020. The Duo runs on Android and is one of their dual-screen devices that gives users new ways to interact with their apps. It also introduces new challenges for developers to provide the optimal experience for our users. So, Microsoft has released the Surface Duo Emulator to allow developers to get a head start optimizing their apps.

In this article, we will go over 2 different ways to run the Surface Duo Emulator on Windows:

  1. Android Studio
  2. Visual Studio

Shared Requirements

There are a few things that need to be set up any way you run the Emulator.

  1. Install Android Studio
  2. Set up Android SDK Settings:

Tools > Android SDK Manager > SDK Tools


Make sure all these SDK tools are installed.

3. Download Duo SDK

4. In File Explorer, navigate to the Emulator run.bat file. The default path is :


Open this file in any text editor and make sure the ANDROID_SDK_LOCATION is set to the location of your Android SDK. You can find your Android SDK Location here:


For example, this is what the ANDROID_SDK_LOCATION path looks like for the above path:


Great! Now we can start on the platform specific setup.

Android Studio

If everything above is properly configured, you can now run the emulator from the command line.

cd into the directory and run the run.bat script.

The emulator should start running!

Note: It can take a while the first time 

Visual Studio

To run the emulator using visual studio, we have a few more steps.

    1 . Open either an existing or new project with an Android head (including Uno, Xamarin, etc.) in Visual Studio 2019.

    I will be using a new Uno  project.

    2. Set up your Android SDK settings

    Tools > Android > Android SDK Manager

    Make sure you have these tools installed:


    3. In order to run our app, the emulator will need to be running. Search for Duo Emulator in windows and select “Duo Emulator for Visual Studio”


    4 . Select “Open”

    This will run a different run.bat script. The difference only being that the visual studio version removes the port definitions.

    5. Back in Visual Studio, you should now see the emulator as an option in your devices dropdown. It will look like this:


    6. Click the big green arrow and your app will pop up in the emulator!


There you have it! Two ways to run the Surface Duo Emulator on Windows. To learn more about developing for Dual Screen Devices, check out the docs.


Breaking Down XAML Grid

If you’re looking to use XAML in your project, chances are you’re going to need to use the Grid layout. Even for seasoned pros, Grids can quickly get complicated. This post will go over the Grid basics and can be used as a reference while building or refactoring your XAML Grids.

The first thing you need to determine is the necessary number of rows and columns. Let’s set up an example with 2 columns and 3 rows.

        <ColumnDefinition />
        <ColumnDefinition />
        <RowDefinition />
        <RowDefinition />
        <RowDefinition />

If you run this code, you won’t see anything. That is because we are just laying down the ground work for our grid, we haven’t given it anything to display. Let’s change that.

  <Grid Background="Pink">
        <ColumnDefinition  />
        <ColumnDefinition  />
        <RowDefinition />
        <RowDefinition />
        <RowDefinition />

    <TextBox Grid.Column="0" Grid.Row ="0" BorderBrush="Black"></TextBox> // 1
    <TextBox Grid.Column="1" Grid.Row ="0" BorderBrush="Black"></TextBox> // 2
    <TextBox Grid.Column="0" Grid.Row ="1" BorderBrush="Black"></TextBox> // 3
    <TextBox Grid.Column="1" Grid.Row ="1" BorderBrush="Black"></TextBox> // 4
    <TextBox Grid.Column="0" Grid.Row ="2" BorderBrush="Black"></TextBox> // 5
    <TextBox Grid.Column="1" Grid.Row ="2" BorderBrush="Black"></TextBox> // 6


We have added a TextBox element for each space in our grid in order to visualize the layout on our page. Each TextBox is arranged by assigning the row and column in a graph coordinate format. Note: each row and column starts with 0.

Here is what our Grid looks like:



The Grid will automatically fill the space it’s in by evenly spacing each row and column. Next, we’ll go over how to control the size of your grid.

<Grid Width="600" Height="300">
        <ColumnDefinition Width="300" />
        <ColumnDefinition Width="300" />
        <RowDefinition Height="*" />
        <RowDefinition Height="Auto" />
        <RowDefinition Height="200"/>

Here we have the same Grid layout as before, but you may have noticed we now have Height and Width properties on our Column and Row Definitions. Furthermore, there is some funky syntax in the Height properties of the RowDefinition elements. There are a few different ways you can define height and width:

  1. Nothing – Grids will auto fill the space they’re in
  2. Integer – Absolute pixel value (ex. 300)
  3. * – Divides available space using a weighted factor
  4. Auto – Defines space based on the contents

With these height and width definitions, this is what our new grid looks like:


Since the columns are both statically set to 300 pixels, let’s walk through each of the rows in the order they are set by XAML:

Row 3 (blocks 5 and 6) : This row is set first since it is a definitive 200 pixels (like out columns)

Row 2 (blocks 3 and 4): This row is set based on it’s contents. Since it contains nothing, it will be set to the minimum size. If we had an image inside one of the blocks, the row would be the size of the image.

Row 1 (blocks 1 and 2): This row is set last and is given the remaining space of the page.

Great! Now we can define rows and their sizes depending on our project’s need! If you have any questions about getting starting with grids or when to use them, feel free to drop into the comment section.


Uno – One Platform to Rule Them All

First, we should start off with what Uno is and why you should care.

As stated on their website, Uno is “The only platform for building native mobile, desktop and WebAssembly apps with C#, XAML from a single codebase. Open source and professionally supported.”

What does this mean?

Well if you have any experience (or not) building a mobile app and a subsequent web app, you have essentially had to build both separately, outside of potentially sharing data through an API.

Before Xamarin, you would even have had to build the iOS and Android apps separately using different languages (Swift/Objective-C and Java/Kotlin respectively). Uno introduces a way to build for iOS, Android, Web, and UWP using shared logic and UI.

This is huge.

Sharing logic between platforms has been the “easy” part for developers. Sharing UI, however, is not. There is a huge difference in UI between Android and iOS and even larger differences between web and mobile. Xamarin.Forms allows us to share UI for Android and iOS but we were still on our own for the web.

Uno enables you to write the UI once, then, using native controls, deploys native UI look and feel to each of your platforms. This means, you write the same code for a button regardless of the platform the button is for, and the user will see the native button for their platform.

How does it work?

The Uno Platform works differently depending on what you’re building.

The platform specific UI is created by taking the visual tree and rendering into what the platform supports:

iOS – UI Kit

Android – ViewGroups and Views

Web – Native controls

The logic is also deployed differently for each platform.

When building a UWP app, Uno runs on top of, well, UWP and WinUI. When building Android and iOS apps, Uno runs on top of the Xamarin Native Stack. Finally, when you’re building a Web App, Uno runs on top of WebAssembly. The mobile apps and web apps all run with Mono runtime. When it all comes together, it looks a little like this:


Well this looks nice, but what’s really happening under the hood?

Let’s break it down:

Android and iOS

  1. You write your C# and XAML code in Visual Studio
  2. Uno takes the code and lets you add any Xamarin specific libraries or tools
  3. Mono runtime executes the C# code

This process is essentially the same as regular Xamarin. The big difference between Xamarin and Uno comes with the ability to run the same UI on the Web.

Web Apps –

  1. You reuse both your logic and UI that you wrote for your mobile apps.
  2. Uno uses the Web Assembly Bootstrapper to take any .NET standard library and execute these files in the JavaScript console.
  3. Mono runtime then executes the code

The ability for Uno to utilize Web Assembly (which is what allows you to write your code in C# and not JavaScript) is what makes Uno so unique.


  1. You reuse both your logic and UI that you wrote for your mobile apps and Web Assembly Apps.
  2. Your code is run through the Windows UI which does not need the Mono runtime to execute.

The big difference here is that UWP apps already have the Windows namespaces and do not need to reference the Uno.UI. The benefit Uno provides here is the ability to reuse the code you’ve already written for mobile and web.

Now that we have an idea of how this beauty works, let’s write some code!

To get started with Uno, follow their instructions here: https://platform.uno/docs/articles/get-started.html

When you create your Uno solution in Visual Studio, there is a similar feel to when you create a Xamarin.Forms solution because of the different projects created for you. Here is a look at the projects that are auto-created:


As you would see in a Xamarin.Forms project, there are separate projects for each platform and a single shared project. The Droid, iOS, UWP, and Wasm projects are all the same as if you had created a blank app for each, the only difference being references to the Uno UI. The magic happens in the Shared project.

Similar to the Shared project in Xamarin.Forms, this is where you will write all your shared logic and UI. Uno provides support for the MVVM, a design pattern many developers are familiar and comfortable with.

So, what does a finished product look like?

Here are examples of each platform using the “TODOS” Demo App from Uno.









These projects all use logic and UI from the shared project. Code once, four apps.

Let’s talk debugging.

Debugging in Uno can be a bit different depending which platform you are trying to debug.

Android and iOS – For mobile, you will use the same Mono debugger you are used to using in Visual Studio, with access to all your favorite breakpoints, value changes, etc.

Web – Currently there is only support for chromium debugging, which means Chrome and Edge.

UWP – Here, the tooling comes from .NET studios which is not as efficient with the mono runtime.

Want to try out Uno but don’t want to go through the steps to get set up through Visual Studio?

Then checkout their playground!


The Uno Playground is a fun and easy way to look at how different items render on different platforms. They make it quick and easy to try out new styles and is great for beginners and tutorials.

What are future features we can look forward to?

  1. Support for MacOS or Linux.
  2. More features from UWP API
  3. Support for smart watches

The true beauty of Uno is that it encompasses what we as developers should all be striving to accomplish – building on top of each others’ accomplishments. We don’t need to re-create the wheel, real innovation happens when you stand on the shoulders of giants and we all move upwards.

Happy coding.

Authored by me, originally posted through freeCodeCamp


Xamarin.Forms vs Xamarin Native

If you’re new to Xamarin (or not), one of the first decisions you’re faced with when starting a new project is whether to use Xamarin.Forms or Xamarin Native. In this article, we’ll go through descriptions of each and which situations are suited best for one or the other.

First, what is the difference?


Image Source: Xamarin Docs

Xamarin.Forms is a way to write your app in C# once, and it will run on both Android and iOS through a shared code base for the logic AND the UI. Xamarin.Forms runs on top of native platforms.

Xamarin Native creates a wrapper around the native APIs for each platform which allows the same look and feel of an app that was built without Xamarin. But, Xamarin developers can build both Android and iOS in C# and have access to the tools offered in the C# community. Xamarin Native requires that you build each app separately, but also allows for more specific configuration for both Android and iOS.

But what about speed?

Altexsoft did an extensive test on speed of native apps, Xamarin Native apps, and Xamarin.Forms apps. You can see the full report here . For bootup speed, native apps are always faster, followed by Xamarin Native apps, and finally Xamarin.Forms.

Image Source: Altexsoft

You will also notice that Android and iOS have significantly different speeds. This is something to keep in mind for your project and whether your users are more likely to be using Android or iOS.

Secondly, if your app is retrieving its data from a REST API, you’ll be concerned about those speeds as well:

Image Source: Altexsoft

Here, the speeds between Xamarin and native are more similar. In fact, Xamarin Android is even a bit faster than the native Android apps.

With all this information, here is a quick guide for when to use each product.

Situations best suited for Xamarin.Forms:

• Apps requiring little platform specific UI
• Apps that need to be built quickly
• Apps that require heavy code sharing

Situations best suited for Xamarin Native:

• High level of platform specific UI
• Apps that need to be as small and as fast as possible
• Apps that require platform specific UI

At the end of the day, there is no wrong choice, Xamarin is best way to build your cross-platform mobile apps.

If you want to dive deeper into Xamarin.Forms or Xamarin Native, read up on the docs here.


Using lookup tables (join tables) in Entity Framework

Very rarely, if ever, do we come across a situation in programming where an entire application relies on isolated database tables that do not have share data between each other. So, then, how do you use Entity Framework to help these tables communicate?

Solution: Join Tables

There are several relationship types your Entity Framework Entities can have with each other.

  1. One-to-One
  2. One-to-Many
  3. Many-to-Many

One-to-One can be handled simply by using a foreign key. For simplicity sake, let’s say we have a Dog class and an Adopter class. A dog can only have one adopter and an adopter can only adopt one dog. Here is what the class setup looks like:

Dog Class:

public class Dog  
    public string Id { get; set; }
    public string Name { get; set; }
    public virtual Adopter Adopter {get; set}

Adopter Class:

public class Adopter 
    public string Id { get; set; }
    public string Name { get; set; }
    public string DogId {get; set;}
    public virtual Dog Dog {get; set}

When this is compiled by Entity Framework, the Id of the Dog with be placed in the virtual Dog column of the Adopter table and the Id of the Adopter will be placed in the virtual Adopter column of the Dog table. And that’s it. Simple.

For a One-to-Many relationship, let’s say an Adopter can adopt multiple dogs (as it should be), but a dog can still only have one Adopter.

This is what the class setup will look like:

Dog Class:

public class Dog  
    public string Id { get; set; }
    public string Name { get; set; }
    public virtual Adopter Adopter {get; set}

Adopter Class:

public class Adopter 
    public string Id { get; set; }
    public string Name { get; set; }
    public string DogId {get; set;}

    public virtual ICollection Dogs {get; set;}

Here, the Dog Class stays the same since it can still only have one Adopter. However, the Adopter class looks a little different. Instead of a single foreign key, we have a collection of Dogs. In the database this looks like a list of Dog Ids.

Finally, we have the Many-to-Many relationship. In this situation, a Dog can have many Adopters and and Adopter can have many Dogs. Now, following the pattern above, you may think that we would just set up a virtual collection in both the Dog and Adopter classes. This, however, is not the case. Instead, we need what is called a Binding or Join Table.

Join Tables allow Many-to-Many relationships in Entity Framework by matching the necessary data (normally an Id).

Here is what our classes will look like:

Dog Class:

public class Dog  
    public string Id { get; set; }
    public string Name { get; set; }
    public virtual ICollection AdoptionMember {get; set;}

Adopter Class:

public class Adopter 
    public string Id { get; set; }
    public string Name { get; set; }
    public virtual ICollection AdoptionMember {get; set;}
public class AdoptionMember 
    public string Id { get; set; }
    public string AdoptionDate { get; set; }
    public int AdoptionFee { get; set;}
    public string DogId {get; set;}
    public string AdopterId {get; set;}
    public virtual Dog Dog { get; set; }
    public virtual Adopter Adopter { get; set; }

Notice that there is a third class, the AdoptionMember. Both the Dog and Adopter classes will have a collection of the AdoptionMember class. The AdoptionMember class has single Foreign Keys for each the Dog and Adoption classes. The AdoptionMember class also has shared data such as the Adoption Date and the Adoption Fee for each individual adoption.

This is a very basic overview of the most common data relationship types you will run into using MVC and how to set up your data when using Entity Framework Code First method.


Selectable Enum Dropdown List Using TagHelpers

This post is going to look into how populate a dropdown list with the contents of an enum using a TagHelper and an HTML Helper.

In case you aren’t familiar with TagHelpers, TLDR:

TagHelpers use server-side code to render HTML concisely and is readable for those not familiar with Razor markup.

If you want to learn more, checkout the docs here.

Alright, let’s dive in with our setup!


public enum DogName


public class Dog
      public DogName DogName{ get; set; }

Make sure both the class and property are public.


In the beginning of your view, be sure to bind the Model:

@model RescueShare.Models.Dog

Then, using our <select> TagHelper in our Razor View to create the actual dropdown:

<select asp-for="DogName"

The asp-for attribute binds the values to the DogName property. Then, asp-items populuates the dropdown with values from our DogName enum using our GetEnumSelectList HTML Helper.

Here are the major benefits for using a TagHelper in this scenario:

  1. Ability to access server-side data
  2. Concise and easy to read
  3. Works with Intellisense

And that’s it! We have gone through how to successfully bind a <select> TagHelper to an enum in a Razor View using an HTML Helper for an ASP.NET Core MVC app!

Web App Series

Basics of .NET Web Apps – Part 3: MVC

Welcome back! Now that we have our environment set up, this post is going to go into more detail about the MVC (Model-View-Controller) design pattern and how it helps us write clear and reusable code.

If this is the first post of the series you are reading, everything should make just as much sense to you as it would if you were following along. However, if you need help setting up your environment, feel free to check out the first two posts here and here.

Let’s dive in!

First, what is a design pattern? A Design Pattern is a commonly used solution to commonly encountered problems. The problem MVC handles, is how to separate business logic from what the end user sees. The reason I’m choosing to use MVC is because it is relatively simple to understand and implement and has a solid community around it (MVC has been around since the 70s but has been an official project type if ASP.NET for about 10 years).

Let’s break it up.

M (Model) – The model is where you hold your business logic and data.

V (View) – The view is what the end user sees and interacts with. We will be setting up our views using Razor syntax.

C (Controller) – The controller is how the model and view communicate and decides which view to render to the user.

The flow looks a little like this:

The Controller renders data from the Model to the View, deciding which view the user needs to see. The user sees the View and sends requests back to the Controller. The Controller then updates the Model. The Model accesses data from the database and sends the data back to the Controller that sends the data up to the View for the user.

Here is a way to visualize:


Let’s walk through an example using our handy Dog class.

First, let’s create out Model.

We set up our dog class in Part 2 and it looked a little like this:

namespace RescueShare.Models
public class Dog
public string ID { get; set; }
public string Name { get; set; }
public string Breed { get; set;}

This class is going to be our Model (conveniently positioned in the Models folder). Notice we have our 3 properties. We could also add some basic functions but we’ll leave it at the properties for now.

Next up is our Controller.

You should already have a “Controllers” folder if you’ve installed MVC as discussed in Part 1 but if not, go ahead and create a folder under your solution called “Controllers”.

Right click on this folder and hit Add -> Controller .

Select MVC Controller with Views…


On the next screen, we are going to tell the Controller which Model we want it to be tied to. In this example, we will be using the Dogs Model:


It will also ask for your DbContext and what you want to name the Controller. Naming convention for Controllers is [Model] + ‘s’. So, since our Model is called “Dog”, our Controller will be called “Dogs”.

And, create!

Take a minute to look around at what just got created:

  1. Brand new Controller class with several built in HTTP requests
  2. A new Views folder named after our model with 5 built in Views (Create, Edit, Delete, Details, Index)
  3. Click into one of the Views, your Model is already wired up and looks like this:
@model RescueShare.Models.Dog

Woo! Now we have used the MVC design pattern!

Now we’ll walk through how these parts interact with the user.

On our Create Dog page


we see our Name and Breed fields. The Controller grabs these from the Model then displays them to the View. If we remove either of those fields from the Model and refresh, the Controller will see that change and update the View.

Now, we can enter some values into the fields. Once saved, the Controller will take these values and bring them to the Model. The Model checks to see if it needs to do anything with these values and if not, stores them in the database.

Here are the 3 main files interacting on this page using MVC:


And there you have it! The very basics of MVC.