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.

Web App Series

Basics of .NET Web Apps: Part 2 – PostgreSQL and Entity Framework

If you’re just jumping into this post, make sure to catch up on the current state of the RescueShare project here.

If you’ve already read up, let’s get started!

So, now we have the bare bones of a web app. But, how are we going to save and access data? We need to set up a database.

I chose to use PostgreSQL as my database based on the fact that it is powerful and is being used more frequently to handle large data. You can learn more about PostgreSQL here but the quick snapshot is that PostgreSQL is an open-sourced object-relational database that uses the SQL language. This blog series does not require experience with SQL but if you’re curious, this is a great place to get comfortable with the basics.

So, let’s download PostgreSQL!

Note: I am going to walk through the steps to download Windows x86-64 Version 11.3, but there are detailed instructions on the PostgreSQL website for other operating systems and versions.

Choose the OS and version you want to work with. I will be working with this:

Click through the prompts.

Make sure you install pgAdmin.


Okay, so now we have a pretty program and a powerful database. Cool. How do we get them to work together?

In many programs, the SQL language is how your logic will communicate with the data. However, we will be using a tool called Entity Framework to make our code cleaner and our lives a little easier.

What is Entity Framework?

TLDR: An object-relational mapper that allows you to use the what you already know and love (.NET) to communicate between your logic in Visual Studio and your data in PostgreSQL (although EF can be used with several other database providers listed here).

In-depth: Read all about Entity Framework (which I highly recommend because it’s super cool) here.

How do we get Entity Framework?

Remember the NuGet Packages we installed from Part 1? Entity Framework was one of those packages.

Why Entity Framework?

EF lets us use the Code First method which basically means we can build our database using classes rather than SQL queries. This allows us to organize our code in a more Object Oriented style and maintain a sleek and easy to-read-look.


Let’s get started.

First, it’s important to understand the basics of EF. There are several types in EF, most importantly being the DbContext. The DbContext communicates with Models to “write” and execute queries. Any tables you want to have in your database will be defined in the DbConext using this syntax:  

public DbSet Dogs { get; set; }
public DbSet Shelters { get; set; }
public DbSet Volunteers { get; set; }

This will look for a corresponding Model. The model is where you will define the columns for your table as properties and it looks 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;}

You can find the DbContext in the Data folder in the Solution Explorer. The default name will be ApplicationDbContext.

You can add models in the Models folder by right clicking on the folder and clicking Add > Class

Remember, every time you add a new model you want to be a table, you must add it to the DbConext.

We’ll talk more later about what these Model files will contain, but for now, just add the properties you want to see as columns in your table.

Now we know how to create tables using Entity Framework. Great!

But how do we actually add them to our database?

First, let’s take a look at what our database already has.

Log in to pgAdmin if you haven’t already (this was installed with PostgreSQL and you can get to it by a quick search in your downloads folder).

Once there, navigate to localhost -> Login / Group Roles 2019-06-25_2326

Add a name to your user (I used the name of my application) and added a password under the Definition tab.

Now you have a user! This is next part could have been done with the default postgres user, however, it’s best to create your own.

Back in Visual Studio, navigate to your startup.cs file. You should see some lines of code that look similar to this

services.AddDbContext(options =>

Currently, this is telling your application to use the default database (SQL Server) but we want to tell it to use pgAdmin. So, change the line that says


to say…


On the next line of code, you can see it is grabbing something called the “DefaultConnection”. This is found in our appsettings.json file. This also holds a default value we are going to change. Right now, you should see something that looks similar to this

"Server=(localdb)\\mssqllocaldb;Database=aspnet ..........

but we want to update it with our user we just created in pgAdmin.

Your updated version should look something like this (with your user information instead):

User ID=rescueshare;Password="";Host=localhost;Port=5432;Database=rescueshare_local;Pooling=true;

Congrats! You have now configured your application to use PostgreSQL!

Next step, getting your data actually into the database.

In the Data folder where you found the DbContext, you should have also seen a Migrations folder. A Migration is how Entity Framework wraps up all your database changes and converts them into SQL to send to PostgreSQL.

You can read more detail about Migrations in Entity Framework here

Remember the Package Manager Console from the first blog post that allowed you to add NuGet Packages? This is also where you will add migrations and update your database.

Here are the steps to adding a migration:

  1. In the Package Manger Console, run Add-Migrations

You will be prompted to add a name. This should be something short about the changes you made. After adding a name, hit enter.

You should see something like this:


This will automatically create a class in your Migrations folder where you can see the changes that will be made.

  1. Now that you have a migration, you need to update your database with the data.

Still in the Package Manager Console, run Update-Database.

Woo! You have just successfully moved all your database changes into your database which you can now view through pgAdmin!

That was a lot of heavy information so I highly recommend reading through some of the docs I linked throughout the post to get a deeper understanding for what we did here.

Up next, we’ll get more into the thick of it and start writing some world altering code.

Web App Series

Basics of .NET Web Apps: Part 1 – Setting up your environment

Like so many developers, I woke up one day with a great idea. The applications were endless, the creativity was flowing, and I was extremely motivated. Then, like many new developers, I opened up Visual Studio and thought now what?

This series is going to walk you through how I wrote my first API. I will share everything from resources, to missteps, to successes, and everything in between. Hopefully this will help someone else bring their ideas to life.

Let’s get started.

Day One:

I should start with talking about the motivation for writing this program.

I love dogs. Like really love dogs, and am a huge rescue advocate. Last weekend, my husband and I flew down to Atlanta (from Boston) and drove up with a 5 month old puppy that was going to be euthanized later that day. The reason we found out about this puppy was from a Facebook post my boss shared in the slack channel. This is often how rescues and potential fosters communicate, which seemed incredibly inefficient to me.

So, I started doing some research, and while I found several databases for people willing to transport, there was no real communication outside of someone having to reach out directly. It’s all unorganized and while the hearts are in the right place, I think there’s a much better way to be going about this.

The 20 hour drive from Georgia gave me plenty of time to think about how I could create something that would help shelters communicate more efficiently with each other and transport volunteers in the area. That brings us to the API. I will be writing a Web API with ASP.NET Core, Entity Framework, Razor Syntax, MVC, and Visual Studio that will create a platform for sharing open spaces in shelters, foster homes, and cars for transports.


Let’s set up our project.

  1. Open Visual Studio and create a new project. I will be using Visual Studio 2017 but may switch sometime during this project to Visual Studio 2019 because it’s new and shiny and exciting.

  2. We’re going to start with a new ASP.NET Core Web Application


You can read up more about .NET here.

On the next screen, we’re going select Web Application (Model-View-Controller) as our pre loaded project template. You of course can use the blank template if you prefer, but this takes out some of the grunt work.


We’re also going to select the Change Authentication button. This will open up a prompt and should filled out with the following settings


By adding authentication, Visual Studio is going to load up Microsoft Identity that will allow us to safely create users without having to write any of the authentication algorithms ourselves.

We will be discussing Identity in later posts as we use it to build our web app but if you’re curious now, read up here

And now we have a project!

What’s next?

  1. NuGet Packages!

What the heck is NuGet Package?

TLDR: A NuGet Package is essentially a tool created and made publicly accessible by other developers so you don’t have to reinvent the wheel. We will use NuGet Packages for our frameworks and other useful tools.

You can read more deeply about NuGet Packages here.

Here is the list of NuGet Packages we will start out with (we may add more later):

Microsoft.AspNet.Mvc by Microsoft
Microsoft.AspNetCore.App by Microsoft
Microsoft.AspNetCore.Identity.EntityFrameworkCore by Microsoft
Microsoft.AspNetCore.Razor.Design by Microsoft
Microsoft.VisualStudio.Web.CodeGeneration.Design by Miscrosoft
Npgsql.EntityFrameworkCore.PostgreSQL by Shay Rojansky

We will go into more detail about what each of them do later but for now, how do we install these?

There are two ways:


Visual Studio comes pre installed with a tool called “NuGet Package Manager” which does exactly what you would expect…manages NuGet Packages.

This can be accessed through Tools > NuGet Package Manager > Manage NuGet Packages for Solution…

It will look like this:


You can then browse, install, update, and delete packages for your solution.


The NuGet Package Manager also has a powershell pre-installed in Visual Studio where you can make all the same changes but with command line prompts. You can find a list of all the NuGet Package Powershell commands here.

Now we have a project with a bunch of pre-built tools. Great!

In Part II, we will venture into using Entity Framework to build our database.

All code for RescueShare can be found on my GitHub.