You can find the code used in this chapter through the following GitHub link: https://github.com/PacktPublishing/Mobile-Development-with-.NET-Second-Edition/tree/master/chapter01/src.

The term cross-platform application development refers to the process of creating a software application that can run on multiple operating systems. In this book, we will not try to answer the question of why, but how to develop cross-platform applications – more specifically, we will try to create a cross-platform application using the toolset provided by Microsoft and .NET Core.

Before we start talking about .NET Core, let's take a look at the process of developing an application for multiple platforms. Faced with the cross-platform requirement, the product team can choose multiple paths that will lead the developers through different application life cycles.

Throughout this book, we will have hypothetical user stories defined for various scenarios. We will start with an overall user story that underlines the importance of .NET Core:

"I, as a product owner, would like to have my consumer app running on iOS and Android mobile platforms, as well as Windows, Linux, and macOS desktop runtimes, so that I can increase my reach and user base."

In order to meet these demands, we can choose to implement the application in several different ways:

• Fully native applications
• Hybrid applications
• Cross-platform

Let's take a look at each of these methods.

Developing fully native applications

Following this path would create probably the most performant application, with increased accessibility to platform APIs for developers. However, the development team for this type of development would require a wider range of skills so that the same application can be created on multiple platforms. Development on multiple platforms would also increase the developer hours that need to be invested in the application.

Considering the scenario presented in the previous section, we would potentially need to develop the client application in Cocoa and CocoaTouch (macOS and iOS), Java (Android), .NET (Windows), and C++ (Linux), and finally build a web service infrastructure using another development platform of our choice. In other words, this approach is, in fact, implementing a multi-platform application rather than a cross-platform one.

Hybrid applications

Native hosted web applications (also known as hybrid applications) are another popular choice for (especially mobile) developers. In this architecture, a responsive web application would be hosted on a thin native harness on the target platform. The native web container would also be responsible for providing access to the web runtime on native platform APIs. These hybrid applications wouldn't even need to be packaged as application packages, but as Progressive Web Apps (PWAs) so that users can access them directly from their web browsers. While the development resources are used more efficiently than in the native cross-platform framework approach, this type of application is generally prone to performance issues.

In reference to the business requirements at hand, we would probably develop a web service layer and a small Single - Page Application (SPA), part of which is packaged as a hybrid application.

Native cross-platform frameworks

Development platforms such as React Native, Xamarin, and .NET Core provide the much-required abstraction for the target platforms, so that development can be done using one framework and one development kit for multiple runtimes. In other words, developers can still use the APIs provided by the native platform (for example, the Android or iOS SDK), but development is executed using a single language and framework. This approach not only decreases development resources, but also saves you from the burden of managing multiple source repositories for multiple platforms. This way, the same source is used to create multiple application heads.

For instance, using .NET Core, the development team can implement all target platforms using the same development suite, thereby creating multiple client applications for each target platform, as well as the web service infrastructure.

In a cross-platform implementation, architecturally speaking, the application is made up of three distinct tiers:

• Application model (the implementation layer for the consumer application)
• Framework (the toolset available for developers)
• Platform abstraction (the harness or runtime to host the application)

In this context, we, in essence, are in pursuit of creating a platform-agnostic application layer that will be catered for on a platform abstraction layer. The platform abstraction layer, whether we are dealing with a native web host or a native cross-platform framework, is responsible for providing the bridge between the single application implementation and the polymorphic runtime component.

.NET Core and Mono provide the runtime, while .NET Standard provides the framework abstraction, which means that cross-platform applications can be implemented and distributed on multiple platforms. Using Xamarin with the .NET Standard framework on mobile applications and .NET Core on the web infrastructure, sophisticated cloud-supported native mobile applications can be created.

As you can easily observe, native cross-platform frameworks offer the optimal compromise between development costs, performance, and the nativeness of the target application, providing developers with an ideal option for creating applications for multiple platforms. From this perspective, .NET (Core) and Xamarin, which together evolved into a cross-platform framework and runtime, has become one of the most prominent development platforms for mobile applications.

We have discussed different ways to implement cross - platform applications and identified the pros and cons of these methodologies. We can now start exploring the .NET ecosystem and cross-platform toolset.

In order to understand the origins of, and motivation for, .NET Core, let's start with a quote:

"Software producers who maximize their product's potential for useful combination with other software, while at the same time minimizing any restrictions upon its further re-combination, will be the survivors within a software industry that is in the process of reorganizing itself around the network exchange of commodity data."

– David Stutz – General Program Manager for Shared Source Common Language Infrastructure, Microsoft, 2004.

.NET Core dates back as early as 2001 when Shared Source Common Language Infrastructure (SSCLI) was shared sourced (not for commercial use) under the code name Rotor. This was the ECMA 335, that is, the Common Language Infrastructure (CLI) standard implementation. Rotor could be built on FreeBSD (version 4.7 or newer) and macOS X 10.2. It was designed in such a way that a thin Platform Abstraction Layer (PAL) was the only thing that was needed to port the CLI to a different platform. This release constitutes the initial steps to migrate .NET to a cross-platform infrastructure.

2001 was also the year the Mono project was born as an open source project that ports parts of .NET to the Linux platform as a development platform infrastructure. In 2004, the initial version of Mono was released for Linux, which would lead to ports on other platforms such as iOS (MonoTouch) and Android (MonoDroid), and would eventually be merged into the .NET ecosystem under the Xamarin name.

One of the driving forces behind this approach was the fact that the .NET framework was designed and distributed as a system-wide monolithic framework. Applications that are dependent on only a small portion of the framework required the complete framework to be installed on the target operating system. It did not support application-only scenarios where different applications can be run on different versions without having to install a system-wide upgrade. However, more importantly, applications that were developed with .NET were implicitly bound to Windows because of the tight coupling between the .NET Framework and Windows API components. .NET Core was born out of these incentives and opened up the doors of various platforms for .NET developers.

Finally, in 2020, .NET Core replaced classic .NET. The unified .NET platform now provides developers with a single runtime and framework that can be used to create cross-platform applications using a single code base.

Semantically speaking, .NET now describes the complete infrastructure for the whole set of cross-development tools that rely on a common language infrastructure and multiple runtimes, including .NET Core Runtime, .NET, also known as Big CLR, the Mono runtime, and Xamarin:

Figure 1.1 – .NET Ecosystem

In this setup, the .NET CLI (Common Language Infrastructure) is made up of the base class library implementation, which defines the standards that need to be provided by the supported runtimes. The base class library is responsible for providing the PAL, which is provided by the hosting runtime under the name of the Adaption Layer. This infrastructure is supported by compiler services such as Roslyn and Mono Compiler (MCS), as well as Just-In-Time (JIT) and Ahead-of-Time (AOT) compilers such as RyuJIT (.NET Core), mTouch, and LLVM (for Xamarin.iOS) in order to produce and execute the application binaries for the target platform.

Overall, .NET Core is a rapidly growing ecosystem with a large number of supported platforms, runtimes, and tools. Most of these components can be found on GitHub as open source projects under the supervision of the .NET Foundation. This open source growth is one of the key factors behind .NET Core reaching its peak today, where the implemented APIs almost fully match those of .NET Framework. This is why the .NET 5.0 release marks the end of the .NET era (as we know it) since the two .NET frameworks are being merged into one in this release, where .NET Core, de facto, replaces .NET itself. Let's now, without further ado, start developing in .NET 5.0.

.NET applications can be developed with Visual Studio on the Windows platform and Visual Studio for Mac (inheriting from Xamarin Studio) on macOS. Visual Studio Code (an open source project) and Rider (JetBrain's development IDE) provide support for both of these platforms, as well as Unix-based systems. While these environments provide the desired user-friendly development UI, technically speaking, .NET applications can be written with a simple text editor and compiled using the .NET Core command-line toolset.

The only intrinsic runtime in the .NET Core CLI is the .NET Core runtime, which is primarily used for creating console applications with access to the complete base class library.

Without further ado, let's create our first cross-platform application with the CLI tools and see how it behaves on multiple target platforms. In this example, we will develop a simple calculator with basic arithmetic operations support as a console application.

Creating a runtime-agnostic application

When developing our calculator, our main goal is to create an application that we can run on multiple platforms (in other words, Windows and macOS). To begin with, we will create our console application on macOS with .NET Core installed:

$ mkdir calculator && cd $_
$ dotnet --version
5.0.100-preview.7.20366.6
$ dotnet new solution
The template "Solution File" was created successfully.
$ dotnet new console --name "calculator.console" --output "calculator.console"
The template "Console Application" was created successfully.
$ cd calculator.console

Important note

In this example, we have used the console template, but there are many other templates available out of the box, such as a class library, unit test project, ASP.NET Core, and more specific templates, such as Razor Page, MVC ViewStart, ASP.NET Core Web App, and Blazor Server App.

The calculator.console console application should have been created in the folder that you specified.

In order to restore the NuGet packages associated with any project, you can use the dotnet restore command in a command line or terminal window, depending on your operating system.

Important note

Generally, you don't need to use the restore command, as the compilation already does this for you. In the case of template creation, the final step actually restores the NuGet packages.

Next, copy the following implementation into the created program.cs file, replacing the Main method:

static char[] _numberChars = new[] { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };
static char[] _opChars = new[] { '+', '-', '*', '/', '=' };
static void Main(string[] args)
{
    var calculator = new Calculator();
    calculator.ResultChanged = (result) =>
    {
        Console.Clear();
        Console.WriteLine($"{Environment.NewLine}{result}");
    };
    // TODO: Get input.
}

Here, we have delegated the calculator logic to a simple calculator state machine implementation:

public class Calculator
{
    private int _state = 0;
    string _firstNumber;
    string _currentNumber = string.Empty;
    char _operation;
    public Action<string> ResultChanged = null;
    public void PushNumber(string value)
    {
        // Removed for brevity
    }
    public void PushOperation(char operation)
    {
        // Removed for brevity
    }
    private int Calculate(int number1, int number2, char 
    operation)
    {
        // Removed for brevity
    }
}

The Calculate method is the actual calculator implementation, and this needs to be added to the Calculator class as well:

private int Calculate(int number1, int number2, char operation)
{
    switch(operation)
    {
        case '+':
            return number1 + number2;
        case '-':
            return number1 - number2;
        case 'x':
            return number1 * number2;
        case '/':
            return number1 / number2;
        default:
            throw new NotSupportedException();
    }
}

Finally, we just need to expand our Main method to retrieve the user inputs. You can now replace the placeholder in the Main method for user input with the following:

while (true)
{
    var key = Console.ReadKey().KeyChar;
    if (key == 'e') { break; }
    if (_numberChars.Contains(key))
    { calculator.PushNumber(key.ToString()); }
    if(_opChars.Contains(key))
    { calculator.PushOperation(key); }
}

Now that our application project is ready (after editing the program.cs file), we can build and run the console application and start typing the input as follows:

$ dotnet run
123+1=124

Here, we used the run command to compile and run our application in the current platform (macOS). If you were to navigate to the build folder, you would notice that, instead of an executable, the CLI actually created a Dynamic Link Library (DLL) file. The reason for this is that, since no other compilation option was defined, the application was created as a framework-dependent application. We can try running the application with the dotnet command, which is called the driver:

$ cd bin/Debug/net5.0/
$ ls
     calculator.console.deps.json 
     calculator.console.pdb                    
     calculator.console.runtimeconfig.json
      calculator.console.dll               
      calculator.console.runtimeconfig.dev.json
$ dotnet calculator.console.dll

Here, it is important to note that we used the description framework-dependent (in this case, the .NET Core App 5.0 runtime). If we were discussing the .NET Framework prior to .NET Core, this would strictly refer to the Windows platform. In this context, however, it refers to an application that is only dependent on the framework itself while being platform-agnostic. In order to test our application on Windows, we can copy the bin folder to a Windows machine with the target framework installed and try running our application:

Figure 1.2 – Running a .NET Core Application

The application binary on Windows Console gives the exact same result as the macOS terminal given that both systems have the .NET 5.0 runtime installed.

Important note

In order to verify that the required framework is installed on the target machine, you can use the dotnet --info or dotnet --list-runtimes commands, which will list the installed runtimes on the target machine.

In order to test the runtime independence of the created demo.dll file, we can try running it with the Mono runtime. On macOS, you can try the following command to execute our application:

$ cd bin/Debug/net5.0/
$ mono calculator.console.dll

If we were to analyze what really is happening in the context of the clean architecture onion diagram, you would notice that the dotnet runtime would represent the infrastructure of the application, whereas the console with the net core app abstraction provided would make up the application UI. While the infrastructure is provided by the target platform, the UI and the application core are portable across platforms:

Figure 1.3 – A Platform - Agnostic .NET Application

In this diagram, the two operating systems have the .NET Runtime installed, which provides the implementation for the .NET BCL, allowing the same binary package to be executed on both platforms.

Taking it one step further, let's now try to package the infrastructure input in the application and prepare a platform-dependent package as opposed to a framework-dependent one.

Defining a runtime and self-contained deployment

In the previous example, we created a console application that is operating system-agnostic. However, it had a dependency on the NETCore.App runtime. What if we want to deploy this application to a target system that doesn't have the .NET Core runtime and/or SDK installed?

When the .NET Core applications need to be published, you can include the dependencies from the .NET Core framework and create a so-called self-contained package. However, by going down this path, you would need to define the target platform (operating system and CPU architecture) using a Runtime Identifier (RID) so that the .NET CLI can download the required dependencies and include them in your package.

The runtime can be defined either as part of the project file or as a parameter during publish execution. Instead of a command parameter, let's modify our project file to include the runtime identifier:

Figure 1.4 – Setting the Runtime Identifier

Here, we have edited the project file to target Windows 10 with the x64 architecture, which would mean that the packaged application would only be targeting this platform.

Now, if we were to publish the application (note that the publishing process is going to take place on macOS), it would create an executable for the defined target platform:

$ nano calculator.console.csproj
$ dotnet publish
Microsoft (R) Build Engine version 16.7.0-preview-20360-03+188921e2f for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
  Determining projects to restore...
  Restored /Users/can/Work/Book/calculator/calculator.console/calculator.console.csproj (in 6.87 sec).
  calculator.console -> /Users/can/Work/Book/calculator/calculator.console/bin/Debug/net5.0/win10-x64/calculator.console.dll
  calculator.console -> /Users/can/Work/Book/calculator/calculator.console/bin/Debug/net5.0/win10-x64/publish/

Here, we have used the terminal editor to modify the project file with the runtime requirements. Once the dotnet publish command execution is finalized, the publish folder will include all the necessary packages from the .NET Core runtime and framework targeting the Windows 10 runtime:

Figure 1.5 – .NET Self-Contained Publish Package

Notice that, once the deployment target platform is defined, an executable file is created and there is no more need for the driver. In fact, the executable's sole purpose here is to act as the access point (host) to the dynamic class library that is created by .NET Core.

In comparison to the previous application package, this package contains the infrastructure content as well as the application core:

Figure 1.6 – Platform-Specific Deployment

Some of the most notable runtimes include Windows 7 to Windows 10 on three different architectures (x86, x64, and ARM), multiple macOS versions, and various distributions and versions of Linux, including OpenSuse, Fedora, Debian, Ubuntu, RedHat, and Tizen. However, considering our goals of creating a cross-platform application, the target framework definition of a .NET project helps us to package platform-agnostic application binaries with only a dependency on the target runtime, not the platform. Let's now take a closer look at possible target framework options.

Defining a framework

In the previous examples, we have been using .NET 5.0 as the target framework. While, as regards the self-contained deployment for this console application, this has proven to be sufficient, if we were preparing a Xamarin or a UWP application, we may potentially need to use .NET Standard for the core application and a platform-specific target for the infrastructure, such as Xamarin.iOS.

The target platform framework can be changed using the <TargetFrameworks> project property. We would have to use the moniker assigned to the desired framework:

Figure 1.7 – Platform Monikers

In this section, using .NET 5.0, we developed a cross-platform console application that can run on both Windows and macOS platforms. We have looked at both runtime- and framework-dependent versions of the same application. The execution of the same console application on Windows' Command Prompt and the macOS terminal, as well as Linux Bash, is an impressive sight:

Figure 1.8 – The .NET console calculator on multiple platforms

As you can see in this sample, the same source code and even the same binary is executed on multiple platforms with the same outcome. This portability of .NET applications should demonstrate the flexibility of the .NET ecosystem, which expands beyond desktop and console applications to mobile development with Xamarin.

The .NET ecosystem is growing at an exponential pace with the new, open source-oriented approach being adopted by Microsoft. Various runtimes and frameworks are now part of community-driven projects that cover bigger portions of the original .NET Framework, which was, ironically, destined to be part of Windows itself.

We have thus far only taken a brief look at the .NET application model and infrastructure. In order to demonstrate the portability of .NET, we have created a simple calculator application, which was then compiled for different runtimes and platforms.

In the following chapter, we will move on to Xamarin, which is the provider of the runtime and the implementation of .NET Standard for mobile platforms. We will implement our first classic Xamarin as well as Xamarin.Forms applications.