But C# has continued to grow and get better over the years. The support of generics, lambda func-tions, LINQ, and asynchronous operations has successfully transformed C# so that it is now properly classified as a multiparadigm programming language. C# code can be traditionally imperative, or the code can be flavored with declarative or functional programming paradigms.
Since its inception, C# has been closely associated with the Microsoft .NET Framework. At the lowest level, .NET provides an infrastructure for the C# basic data types (int, double, string, and so forth). But the extensive .NET Framework class library provides support for many common choresencoun-tered in many different types of programming. These include:
Math
Debugging
Reflection
Collections
Globalization
File I/O
Networking
Security
Threading
Web services
Data handling
XML and JSON reading and writing
Here’s another big reason for C# and .NET to be regarded as a compelling cross-platform solution:
It’s not just hypothetical. It’s a reality.
Soon after Microsoft’s announcement of .NET way back in June 2000, the company Ximian (founded by Miguel de Icaza and Nat Friedman) initiated an open-source project called Mono to create an alternative implementation of the C# compiler and the .NET Framework that could run on Linux. A decade later, in 2011, the founders of Ximian (which had been acquired by Novell) founded Xamarin, which still contributes to the open-source version of Mono but which has also adapted Mono to form the basis of cross-platform mobile solutions.
The year 2014 saw some developments in C# and .NET that bode well for its future. An open-source version of the C# compiler, called the .NET Compiler Platform (formerly known by its code name “Roslyn”) has been published. And the .NET Foundation was announced to serve as a steward for open-source .NET technologies, in which Xamarin plays a major part.
In March 2016, Microsoft acquired Xamarin with the goal of bringing cross-platform mobile development to the wider Microsoft developer community. Xamarin.Forms is now freely available to all users of Visual Studio.
A single language for all platforms
For the first three years of its existence, Xamarin focused mainly on compiler technologies and three basic sets of .NET libraries:
Xamarin.Mac, which has evolved from the MonoMac project.
Xamarin.iOS, which evolved from MonoTouch.
Xamarin.Android, which evolved from Mono for Android or (more informally) MonoDroid.
Collectively, these libraries are known as the Xamarin platform. The libraries consist of .NET versions of the native Mac, IOS, and Android APIs. Programmers using these libraries can write applications in C# to target the native APIs of these three platforms, but also (as a bonus) with access to the .NET Framework class library.
Developers can use Visual Studio to build Xamarin applications, targeting iOS and Android as well as all the various Windows platforms. However, iPhone and iPad development also requires a Mac connected to the PC through a local network. This Mac must have Xcode installed as well as Xamarin Studio, an OS X–based integrated development environment that lets you develop iPhone, iPad, Mac OS X, and Android applications on the Mac. Xamarin Studio does not allow you to target Windows platforms.
Sharing code
The advantage of targeting multiple platforms with a single programming language comes from the ability to share code among the applications.
Before code can be shared, an application must be structured for that purpose. Particularly since the widespread use of graphical user interfaces, programmers have understood the importance of separating application code into functional layers. Perhaps the most useful division is between user-interface code and the underlying data models and algorithms. The popular MVC (Model-View-Controller) application architecture formalizes this code separation into a Model (the underlying data), the View (the visual representation of the data), and the Controller (which handles input from the user).
MVC originated in the 1980s. More recently, the MVVM (Model-View-ViewModel) architecture has effectively modernized MVC based on modern GUIs. MVVM separates code into the Model (the under-lying data), the View (the user interface, including visuals and input), and the ViewModel (which man-ages data passing between the Model and the View).
When a programmer develops an application that targets multiple mobile platforms, the MVVM architecture helps guide the developer into separating code into the platform-specific View—the code that requires interacting with the platform APIs—and the platform-independent Model and View-Model.
Often this platform-independent code needs to access files or the network or use collections or threading. Normally these jobs would be considered part of an operating system API, but they are also jobs that can make use of the .NET Framework class library, and if .NET is available on each platform, then this code is effectively platform independent.
The part of the application that is platform independent can then be isolated and—in the context of Visual Studio or Xamarin Studio—put into a separate project. This can be either a Shared Asset Project (SAP)—which simply consists of code and other asset files accessible from other projects—or a Portable Class Library (PCL), which encloses all the common code in a dynamic-link library (DLL) that can then be referenced from other projects.
Whichever method you use, this common code has access to the .NET Framework class library, so it can perform file I/O, handle globalization, access web services, decompose XML, and so forth.
This means that you can create a single Visual Studio solution that contains four C# projects to tar-get the three major mobile platforms (all with access to a common PCL or SAP), or you can use Xamarin Studio to target iPhone and Android devices.
The following diagram illustrates the interrelationships between the Visual Studio or Xamarin Studio projects, the Xamarin libraries, and the platform APIs. The third column refers to any .NET-based Windows Platform regardless of the device:
The boxes in the second row are the actual platform-specific applications. These apps make calls into the common project and also (with the iPhone and Android) the Xamarin libraries that implement the native platform APIs.
But the diagram is not quite complete: it doesn’t show the SAP or PCL making calls to the .NET Framework class library. Exactly what version of .NET this is depends on the common code: A PCL has access to its own version of .NET, while an SAP uses the version of .NET incorporated into each particular platform.
In this diagram, the Xamarin.iOS and Xamarin.Android libraries seem to be substantial, and while they are certainly important, they’re mostly just language bindings and do not significantly add any overhead to API calls.
When the iOS app is built, the Xamarin C# compiler generates C# Intermediate Language (IL) as usual, but it then makes use of the Apple compiler on the Mac to generate native iOS machine code just like the Objective-C compiler. The calls from the app to the iOS APIs are the same as though the application were written in Objective-C.
For the Android app, the Xamarin C# compiler generates IL, which runs on a version of Mono on the device alongside the Java engine, but the API calls from the app are pretty much the same as though the app were written in Java.
For mobile applications that have very platform-specific needs, but also a potentially shareable chunk of platform-independent code, Xamarin.iOS and Xamarin.Android provide excellent solutions. You have access to the entire platform API, with all the power (and responsibility) that implies.
But for applications that might not need quite so much platform specificity, there is an alternative that will simplify your life even more.
Source of Information : Creating Mobile Apps with Xamarin.Forms
No comments:
Post a Comment