Hands-On Mobile Development with .NET Core

Following this path would create probably the most performant application, with increased accessibility to the platform APIs for the developers. However, the development team for this type of development would require specific know-how and skill sets so that the same application can be created on multiple platforms, also increasing the developer hours that need to be invested in the application.

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

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 right from their web browsers. While the development resources are even more efficiently used than 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. The other parts can be hosted as a web application.

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 development language for multiple runtimes. In other words, the developers are still using the APIs provided by the native platform (for example, Android or iOS SDK), but the development is executed in a single language and framework. This approach not only decreases the development resources, but also saves you from the burden of managing multiple source repositories for multipleplatforms. 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 and language, thus 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:

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 it's on the native web host or the 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 the .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.

Some of the most notable projects that are generally used in modern .NET applications, as well as cross-platform mobile applications, are as follows:

To begin with, we will create our console application on macOS that has .NET Core installed:

$ mkdir demo && cd $_
$ dotnet --version
2.1.301
$ dotnet new console
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on /demo/demo.csproj...
 Restoring packages for /demo/demo.csproj...
 Generating MSBuild file /demo/obj/demo.csproj.nuget.g.props.
 Generating MSBuild file /demo/obj/demo.csproj.nuget.g.targets.
 Restore completed in 236.91 ms for /demo/demo.csproj.

Restore succeeded.

Now, the helloworld console application should have been created in the folder that you specified in the first step.

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.

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

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/netcoreapp2.1/
$ ls
demo.deps.json demo.pdb demo.runtimeconfig.json 
demo.dll demo.runtimeconfig.dev.json 
$ dotnet demo.dll
Hello .NET Core

Here, it is important to note that we used the description framework-dependent (in this case, the NETCore.App 2.1 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:

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/netcoreapp2.1/
$ mono demo.dll
Hello .NET Core

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 .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:

Here, we have edited the project file to target Windows 10 with the x64 architecture. 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 demo.csproj
$ dotnet publish
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

Restoring packages for /demo/demo.csproj...
 Installing runtime.win-x64.Microsoft.NETCore.DotNetAppHost 2.1.1.
 Installing runtime.win-x64.Microsoft.NETCore.DotNetHostResolver 2.1.1.
 Installing runtime.win-x64.Microsoft.NETCore.DotNetHostPolicy 2.1.1.
 Installing runtime.win-x64.Microsoft.NETCore.App 2.1.1.
 Generating MSBuild file /demo/obj/demo.csproj.nuget.g.props.
 Generating MSBuild file /demo/obj/demo.csproj.nuget.g.targets.
 Restore completed in 18.81 sec for /demo/demo.csproj.
 demo -> /demo/bin/Debug/netcoreapp2.1/win10-x64/demo.dll
 demo -> /demo/bin/Debug/netcoreapp2.1/win10-x64/publish/

The publish folder, in this case, would include all the necessary packages from the .NET Core runtime and framework targeting the Windows 10 runtime:

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.

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, Tizen, and so on.

In the previous examples, we have been using netcoreapp2.1 as the target framework. While, for the self-contained deployment for this console application, this proves to be sufficient, if we were preparing a Xamarin application or a UWP. Net Standard, we would have been better off using target platform frameworks 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: