37 Xamarin Interview Questions Mobile Devs Must Know (ANSWERED)

Xamarin is a Cross Platform Mobile Development technology by Microsoft where we can develop the native app using the same code base across all platforms (iOS, Android, UWP) using the C# language. Xamarin uses two approaches for the app development:

• Xamarin.Forms and
• Xamarin Native.

Xamarin.Forms uses MVVM & XAML while Xamarin Native uses native UI technology and MVC or MVVMCross Architecture.

Xamarin allows two different ways of creating applications, based on the amount of code reusability and customization:

• The first approach is the Traditional Native Approach wherein platform-specific apps using Xamarin.iOSiOS and Xamarin.Android can be made. This way of creating apps is generally used when there is a lot of customization specific to the platform is required as it allows direct access to platform-specific APIs. Xamarin.iOS is used for iOS applications and Xamarin.Android is used to create Android applications.

• The second approach is creating apps through Xamarin.Forms approach. Xamarin.Forms are used when there is a possibility of reuse of a lot of platform-independent code and the focus is less on custom UI. The platform-independent code is separated and kept in Shared Project or PCL or .NET Standard Library and Platform Specific projects consume this common code by including it.

Xamarin.Forms can consists of four (this varies based on requirements) projects under one solution.

• .NET Standard, PCL or Shared Project
• iOS Project
• Android Project
• UWP Project

Here, .NET Standard, PCL or Shared Project contains all UI & Business logic inside it.

iOS, Android, UWP contains platform specific code containing Renderers or Dependency Services Implementations.

.NET Standard Libraries is a way to share common code over multiple runtimes. .NET Standard is a set of specifications which various .NET runtimes adhere to and hence code written for one version of .NET Standard works on multiple versions of .NET runtimes like .NET Core, Mono, etc.  You can write your code and compile it into .NET Class Library and share it with others.

1. It allows you to share code across multiple projects
2. When you refactor, all affected references are updated at once.

Disadvantage

1. You cannot do the conditional compilation for specific platforms using the #if directive

It is somewhat similar to PCL but with a simpler model for platform support.

Shared Projects are the usual .NET application projects that contain code files and assets. Shared Projects are meant to be included in other projects and help in code reuse. It is a code level sharing technique.

A cross-platform application that supports iOS, Android, and Windows would require an application project for each platform and a separate Shared Project for the code common to all.

So, if you are creating a cross-platform app for Android, iOS, and Windows, you will usually have the following projects

• Shared Project – the Shared Project that contains the code which is common for all platforms viz iOS, UWP, Android
• AppAndroid – the Xamarin.Android project that specifically calls the underlying .NET APIs exposed for Android
• AppiOS – Xamarin.iOS application project that specifically calls the underlying .NET APIs exposed for iOS
• AppWindows – Windows application project that utilizes exposed Windows APIs and specific to UWP (Universal Windows Platform)

A Shared Project is not directly compiled. In other words, no DLL file is produced in the compilation process. Instead, the files are compiled into the same DLL as the project that references it. This way, it is possible to write blocks of platform-specific code in the Shared Project that will only be compiled by the specific platform.

The advantages of using this technique are:

• Allows you to share common code across multiple projects.
• The shared code can be branched based on the platform using compiler directives (eg. using #if __ANDROID__ or #if __IOS__)
• Application projects can include platform-specific references that the shared code can utilize

Disadvantages:

They do not produce any output assembly of their own. Hence, not used for sharing and distributing to other developers

There are three ways we can share code:

• Shared Project: Here, if required, we write platform specific code using #if compiler directives.
• Portable Class Libraries: Here, we create a PCL targeting the platforms we wish to support and then we use Interfaces & Dependency Services to use platform specific functionality.
• .NET Standard Libraries: It works similar to the PCL and requires Interfaces to work with platform specific functionality.

Xamarin.Android applications depend on Microsoft's Mono Virtual Machine. Mono is Microsoft's open-source implementation of the .Net Framework based on open standards for C# and CLR. Launched in the year 2001, it was mainly created to allow .Net applications to work on Linux platform, but was later modified to support development on various devices including embedded systems.

In Xamarin, Mono works in parallel with Android's ART. On Android, most of the system facilities like Audio, Graphics, OpenGL, and Telephony are not available directly to native applications, they are only exposed through the Android Runtime Java APIs residing in one of the Java.* namespaces or the Android.* namespaces. The native applications interact with the exposed .NET APIs. These APIs then, through Android Binding call the underlying Android Runtime Java APIs. The architecture is roughly like this.

Custom renderers allow the Generic Xamarin.Forms control to be customized in behavior and look as per the platform they are going to be used on. This enables developers to give a native look and behavior to the otherwise Generic Xamarin.Forms Control.  

Xamarin Forms controls are NOT rendered directly on the native platform. Every Xamarin.Forms control has an accompanying renderer for each platform that creates an instance of a native control. The properties from the Xamarin Forms control are translated across to the native control, then the native control is placed in the native layout, which then gets rendered by the platform.  

Custom Renderers allow developers to customize the appearance and/or behavior of the control by writing their custom classes. Custom Renderers can be defined to have a custom behavior or appearance for one platform while allowing the default behavior on other platforms or they can be defined for each platform and provide customization for each different platform like iOS, Android, and the Universal Windows Platform (UWP).  If instead of changing the complete behavior and appearance only some trivial changes are required then 'Effects' can be used as an alternative.

Effects, like Custom Renderers, allow a developer to customize controls for a specific platform. Effects are preferred over Custom Renderers when small styling changes are required instead of a complete layout or behavior change. Custom Effects are created for platform-specific projects by extending the base class PlatformEffect. Once created, they can be attached to the control it is meant for.  

Effects don't have any type related information about the control they are attached to and hence if they are specified with a wrong control they should gracefully degrade.  

Effects are reusable and can be parameterised to extend its reusability.  

Triggers allow us to declare actions in XAML which changes the appearance of the control when specific condition is met for specific control property or specific event is raised.

We can add triggers to the control-level, page-level or application-level in the resource dictionary. There are four types of Triggers.

• Property Trigger: executed when a property on a control is set to a particular value
• Data Trigger: It is similar to the property trigger but it leverages the use of data binding
• Event Trigger: occurs when some specified event is raised on the control
• Multi Trigger: allows multiple trigger conditions to be set before an action occurs

XAML Markup Extension helps us extend the power of providing the value to the attributes of the control from the different sources instead of just providing string literals.It is just a different way to express an attribute of an Element. Any attribute setting which is enclosed within curly braces are simply known as Markup Extensions.

<BoxView Color="{StaticResource PrimaryThemeColor}" />

Custom Renderers provide an approach for customizing the look and feel & behaviors of the Xamarin.Forms controls specific to platforms. Thus it enables for us to customize any Xamarin.Forms visual elements natively. Moreover, if something is not possible with Xamarin.Forms for some visual elements, we can achieve it using Renderers.

TestFlight is now owned by Apple, and is the primary way to beta test your Xamarin.iOS apps.

View-to-View Binding means binding a value of one property of one control to the other control's property in the XAML file itself.

• PCL has an output assembly as DLL while Shared Project has no output assembly.
• Files inside PCL are treated as part of PCL while in Shared Project, files are treated as part of the referencing project and compiled into that assembly.
• PCL contains neat and clean platform independent code while Shared Project consists of many #if compiler directives to differentiate code among platforms.
• PCL is the best approach if good project architecture is the main concern instead of Shared Project.
• PCL uses the Interfaces and DependencyServices to access platform specific features while Shared Project can assess them directly.
• PCL has less compile time errors while Shared Project has many chances of compile time errors while switching among platform specific projects.
• PCL is used if less platform specific code is required. Shared Project is used when lot of platform specific code is required. However, this is not true all the time. Choice is always on the developer.

• AXML and XAML are two different XML specifications.
• AXML is just supported/available for Xamarin.Android.
• XAML is the way Xamarin Forms could standardize Cross Platform UI based on XML specification.
• XAML is the way Xamarin Forms could standardize Cross Platform UI based on XML specification.

If you are using native Xamarin Android you will do UI using axml, if using Forms then using XAML.

The main difference is that in Xamarin Forms, you share NOT ONLY the business logic, but also the UI. In Xamarin forms, you'll use basic components on all platforms (Button, Label, etc). That's the reason why it's called Xamarin.Forms, because it's suitable for basic forms.

But for Xamarin Native (Xamarin.iOS and Xamarin.Android ), you'll create a UI per platform (One for iOS, one for Android). You can do much more with Xamarin Native, because you'll use native components.

Using XAML compiler, we can directly compile XAMLs into intermediate language (IL) optionally.

Benefits:

• It performs compile time checking of any errors in XAML, thus notifies the user for any errors at compile time.
• It removes some of the overhead and instantiation time for XAML elements.
• It doesn't include the XAML files into the final assembly and thus it reduces the assembly size.

This method is auto-generated when we add any new XAML Page to the project. It instantiates and initializes all the objects which we have defined into the XAML file. It connects them with each other based on their parent child relations. It attaches the Event Handlers we defined in the code with the Events, we set in the XAML. Then, it generates the whole tree of objects like a content of a page.

We should never access any control of our page before this call because before this call, none of the controls get initialized or exist and so, we will get an Exception.

When we want the hierarchical navigation of pages like forward or backward navigation, we may instantiate a very first page (for example: MyFirstPageXaml) wrapped into a NavigationPage and then assign it, to a MainPage property of App.cs class. For example:

public App ()
{
    MainPage = new NavigationPage (new MyFirstPageXaml ());
}

This causes the MyFirstPageXaml page instance to be pushed into the navigation stack and this page becomes the active page and acts as a Root Page of the app. Thus, it creates a stack of pages which are being pushed in LIFO (Last-In-First-Out) manner. It is recommended that we pass only "ContentPage" instances into the NavigationPage.