Xamarin Interview Questions and Answers

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.

It notifies the client that a value of specified property is changed. Generally, we implement this interface to the object ( ViewModel ) which is bound to the target UI elements.

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.

The main advantage of using XAML is it provides a clean separation of markup and code, so while the developer can concentrate on the behavior of the application (i.e. the code), the graphic designers can focus on the look and feel of the application. XAML can be compiled, and it takes full advantage of the Longhorn graphics subsystem, helping developers to produce great visual effects. In a XAML file, there is a clear hierarchy of graphical elements and it is easy to understand the GUI design of the app i.e. which element encloses which other elements. The separation of concerns ensures that any changes to the visual aspects of the application may not affect the business logic. The drawbacks of using XAML are, XAML cannot contain any logic, all the logic has to go into separate code files. It does not directly support conditional processing or loops for repetitive processing of tasks

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 .

FreshMvvm is a super light Mvvm Framework designed specifically for Xamarin.Forms only. It's designed to be Easy, Simple and Flexible. It is easy to learn and uses convention over configuration. Fresh MVVM deviates a little from MVVM as it uses the concept of Page and PageModel instead of View and ViewModel.

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.

While developing apps with Xamarin.Forms, you will find that certain native platform-specific functionalities are not present in the Xamarin.Forms API. This is because of the generic nature of Xamarin.Forms. Xamarin.Forms allow apps to call into platform-specific functionality from shared code. This functionality enables Xamarin.Forms apps to do anything that a native app can do. You need to necessarily define an interface and write platform- specific implementations of that interface in the platform project. Dependency service will find the correct implementation of that interface in the various platform projects. Xamarin.Forms apps need four components to use DependencyService:

**Interface – **The required functionality is defined by an interface in shared code. This needs to be
implemented by each platform

Implementation Per Platform – The implementation of the above-mentioned interface for each platform.

**Registration – **To find the correct implementation of the interface for the suitable platform at runtime, it is

required that each platform implementation class of the interface be registered with the DependencyService at runtime Invoking Dependency Service- It is required that there be an explicit invocation of the Dependency service, which will then allow the Dependency service to choose the appropriate implementation based on the platform. The structure of the application is explained by the following diagram:

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

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

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

**The primary benefits of using this approach are:**

1. It allows you to share code across multiple projects
2. When you refactor, all affected references are updated at once. Disadvantage
3. 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.

Xamarin provides three common approaches to share code between Cross-Platform Applications:

1. .NET Standard Libraries
2. Shared Projects

3. Portable Class Libraries (Deprecated)

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.

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.

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.

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.

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.

ControlTemplate decides how a Control should look, means it defines the representation style for a Control . Example: Button can contain Image and Text . DataTemplate decides the visual structure for underlying data, means how you would like to represent data.

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.

Behaviors help us in adding functionality to user interface controls without creating a subclass of it. Required functionality is implemented using the Behavior class and attached to that control as if it is part of this control. Examples where we can use Behaviors are: An Email Validater in an Entry Creating a rating control using a Tap Gesture Controlling Animation Adding some effect to a control

To provide a seamless experience to users iOS provides metadata to the system in the form of info.plist (information property list file). This metadata is used by the system to identify the app, document types it supports, and to facilitate the launch of apps. The property list can be accessed by the system at runtime. It containskey-value pairs. These key-value pairs describe the various behaviors and configuration options for the app. For every app, the Xcode provides info.pList files with default key values which can be later edited to suit the needs of the application

A ViewCell is a small individual element which re-presents a single item of the ListView or Table . A ViewCell is actually not a Visual Element, but it is a description of the template which creates a Visual Element. List of Built-in cells: TextCell : It is a cell that consists of a Title / Primary text and a Detail / Secondary text label. ImageCell : It is basically a TextCell but also includes an Image component on the left. SwitchCell : This cell consists of the Label and one Toggle Switch. EntryCell : This cell contains a Label and single line of textbox that can be used to enter the data.

Every BindableObject has an extension method, called SetBinding , which takes View 's bindable property and the corresponding property from the ViewModel which you want to bind to.

Page is generally a Visual element which occupies all or most of the screen space containing a single child. Content Page: It displays a single View generally containing a ScrollView or StackLayout . Master Detail Page: It manages two panes of information, generally used for Sliding Panel/Drawer. Navigation Page: It manages the navigation stack of Pages. Tabbed Page: Used when navigation among children pages, using Tabs, is required. Templated Page: It displays full screen content with a control template. Carousel Page: It allows swipe gestures between sub pages similar like Gallery.

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}" />

Suppose we have some elements added into the StackLayout with any of the Expand options above, all of the child elements will try to occupy more space if available to use. If StackLayout has any unused space, then the unused space is shared equally by all the child elements which request the Expansion by using " AndExpand " suffix in the Horizontal or Vertical LayoutOptions . If all the space is used in the StackLayout , then the " AndExpand " has no effect.

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.

ResourceDictionary is used to define the XAML Resources which can be re-used more than once throughout the Xamarin.Forms application. XAML resources are the definition of objects which can be used more than once. ResourceDictionary allows all such resource objects declared at one place. Generally, we can define Styles , ControlTemplates , DataTemplates , Colors and Converters into the ResourceDictionary . In XAML, these resources can be accessed using the StaticResource Markup Extension. ResourceDictionary can be declared at either Element Level (inside specific Element ), Page Level (inside

Page ) or Application Level (inside
App.xaml).

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.

There are different Markup Extensions available to access from x prefix of the namespace declaration such as: x:Static : Used when we want to access static properties, fields, or Enum members in XAML elements. x:Reference : Used when we want to declare the reference of some named element into some other element of the same XAML Page. x:Type : Used when we want to set the type of some attribute to System.Type object. x:Array : Used when we want to construct the array of objects of some specific type. x:Null : Used when we want to set the value of some attribute to a null .

DependencyService is used to call the native platform specific implementation of some feature from the PCL or Shared project. Thus, it helps us in doing anything that native app can do. Steps: Interface: Define an interface for specific feature into the PCL or shared Project. Implement it per Platform: Add class into the Platform specific project and implement this interface into that class by inheriting this interface to it. Registration: Register each of these platform specific classes with DependencyService by providing metadata attributes to it. Now, we can access the native implementation of this class into PCL or Shared project by DependencyService .

We can use OnPlatform Tag in XAML to achieve this. OnPlatform Tag provides a way to declare platform specific values to some properties directly into XAML. For example if we want to provide different font size to a Button for each platform, it can be achieved like:

<Button VerticalOptions="CenterAndExpand" Text="Save"\>
<Button.FontSize>
<OnPlatform x:TypeArguments="x:Double"\>
<On Platform="iOS"\>15</On\>
<On Platform="Android"\>13</On\>
<On Platform="WinPhone"\>14</On\>
</OnPlatform\>
</Button.FontSize\>
</Button\>

We can bind a ViewModel directly into the XAML or we can bind it into XAML's backend .cs file. When we bind a ViewModel in XAML, it is said a View-First Construction in XAML. When we bind a ViewModel in Code behind, it is said a View-First Construction in Code behind.

The various features of Fresh MVVM are: Every Page must be associated with a Page Model The PageModel can have an Init method to initialize Model variables and a ReversInit() method (a destructor) that is called when a model is popped with object Page Model allows dependencies to be automatically injected into the Constructor A Page must have a corresponding PageModel, with naming important so an ImagePageModel must have an ImagePage PageModel can have dependencies automatically injected into the Constructor The navigation in Fresh MVVM takes place between Page Models. Supports automatic wiring of BindingContext Supports automatic wiring of Page events (eg. appearing) FreshMvvm comes with a built-in Inversion of Control Container Page Model Important Methods: Init(): The Init() method is called when the page is about to be loaded. User can pass an "object" to this method to allow setting up the Page with external data before it is being loaded ReversInit(): The ReverseInit() method is called when the page I about to be popped from the stack. It allows returning an "object" which can contain the data returned by the Page ViewIsDisappearing(): ViewisDisappearing() is called when the view is about to disappear from the screen ViewIsAppearing(): ViewisIsAppearing() is called when the view is about to appear on the screen.

Xamarin.Essentials is a library that provides cross-platform APIs for native device features. Like Xamarin itself, Xamarin.Essentials is an abstraction that simplifies the process of accessing native functionality. Some examples of functionality provided by Xamarin.Essentials include: Device info File system Accelerometer Phone dialer Text-to-speech Screen lock

MVVMCross is a .NET cross-platform MVVM framework. It allows making cross-platform solutions, for platforms such as Xamarin.Forms, Xamarin.Android, Xamarin.iOS, Xamarin.Mac, Xamarin.tvOS, UWP, and WPF. It is currently inactive state of development. MVVM Cross requires the application to be divided into two parts: the Core and the UI. The Core part contains the View Models, Service, Models, and the Business logic whereas the UI parts consist of the different Views and platform-specific code that interacts with the Core. The views are View Screens that contain the graphical content. In addition to Core and UI, the application may contain additional libraries for various functionalities. The various high-level features that MvvmCross provides are: An MVVM architecture pattern A flexible Navigation system Data Binding to allow source-target automatic binding Platform specifics support Inversion of Control container Dependency Injection engine Plugins for common functionalities. A lot of customizable plugins are available for common tasks. The cons of using MVVM Cross are: It has a steep learning curve and lacks a Wiki for how to get started developing apps.

The Xamarin platform consists of a number of elements that allow you to develop applications for iOS and Android: C# language – Allows you to use a familiar syntax and sophisticated features like Generics, LINQ and the Parallel Task Library. Mono .NET framework – Provides a cross-platform implementation of the extensive features in Microsoft’s .NET framework. Compiler – Depending on the platform, produces a native app (eg. iOS) or an integrated .NET application and runtime (eg. Android). The compiler also performs many optimizations for mobile deployment such as linking away un-used code.

**IDE tools **– The Visual Studio on Mac and Windows allows you to create, build, and deploy Xamarin
projects.

MVVM Light is another Framework that allows the creation of Enterprise-Grade apps using the MVVM Architectural pattern on Xamarin. MVVM Light enables developers to create and develop MVVM applications on a variety of platforms like Xamarin.Forms, Xamarin.Android, Xamarin.iOS, UWP, and WPF. It allows you to separate the View from Model and hence right more testable and extensible applications. It is not in active development now. It does not support async commands. A typical MVVM Light application is divided into the following parts:

**View: **It is a platform-specific user interface that is associated with the screen

View Model: IT exposes the data and the properties related to data ViewModel Locator: It registers custom ViewModels. MVVM Light advocates the use of a Messenger for loosely-coupled communication everywhere in the app, including data binding, dialogs, and navigation: Supports two-way data binding Supplies a DelegateCommand class for wiring up ViewModel commands.

A Service is an application component that allows a user to run long operations that do not require user interaction. Services are broadly classified into Started and Bound Service. A Started Service is one which is invoked by call StartService(). Once started the service can run indefinitely in the background, even after the component that started it is destroyed. Usually, a started service performs a specific operation (like downloading a file) and stops itself. A User-defined Started Service can be created by either extending the Service class or by extending the Intent Service. An Intent Service is a special type of Service which stops itself automatically after completing the task assigned.

A Bound Service is created when the application component calls BindService() to bind to a service. Bound Service is like a Client-server interface that allows components to interact with the service, send requests, get results, etc. A Bound service can be accessed by the components within an application and also by components residing in other applications (if it is exported/exposed). Bound Services only keep running till they have a client associated with it. When all clients Unbind the service the service stops.

The various types of keys defined in _info.plis_t files are:

1. Core Foundation Keys: The keys specified in use the prefix 'CF' to distinguish them with other keys. They provide information related to bundles which help in loading them and knowing their content
2. Launch Services Keys: They use the prefix LS to distinguish them from other keys. They provide metadata related to the launch time behavior of the app
3. Cocoa Keys: Cocoa keys use the prefix NS to distinguish them from other keys. Cocoa keys define metadata related to Cocoa Touch Apps
4. iOS Keys: UIKit keys use the prefix UI to distinguish them from other keys
5. App Extension Keys: App extensions enable you to provide features to other apps in iOS and macOS. App Extension Keys provide system information about an app extension's capabilities and intents.

The Xamarin.Forms Entry is used to specify single-line text input. It is like a TextBox where the user can enter text characters. It, just like the Editor view, supports multiple keyboard types. Entry can also be used as a password field where each character entered is replaced by a * on the Entry thereby hiding the actual characters. Editor, just like entry is used to enter the text input, the difference being the Editor allows multiple- line input. Editor also has a Tet property that represents the text that is associated with the Editor control. Editor and Entry can be both used to specify placeholder text thereby allowing the developer to give hints with sample text to make it easy for the developer to enter text in a correct format.

Xamarin.iOS supports linking with both native C libraries and Objective-C libraries. For linking with third-party C libraries, it is required that all the libraries be linked statically. Following are the steps one needs to follow to consume third party C Libraries: Bring the Library into your project: Select your project from the Solution Explorer and locate the file on your disk and add it to the project. When prompted, tell Visual Studio for Mac or Visual Studio to copy it into the project. After adding it, find the library in the project, right-click on it, and set the Build Action to none. Configure Xamarin.iOS to link the library: Now on the project options of your project, add in iOS Build's extra argument, the "-gcc_flags" option followed by a quoted string that contains all the third-party libraries that are required for your project Access the methods from the library: For this, use Mono's Platform Invoke (P/Invoke) to access these methods from C#.

Behaviors are usually of following types:

**Xamarin.Forms behaviors: **classes that derive from the Behavior or Behavior class where T is the type of

control to which the behavior should apply

**Attached behaviors: **These are static classes with one or more attached properties

Reusable Behaviors: Behaviors that are reusable across more than one application. Behaviors are written for a specific control type, and hence, they are supposed to be added only to a compatible control. Attempting to attach a behavior to an incompatible control will result in an exception being thrown.

The C# source makes its way into a native app in very different ways on each platform: iOS – C# is ahead-of-time (AOT) compiled to ARM assembly language. The .NET framework is included, with unused classes being stripped out during linking to reduce the application size. Apple does not allow runtime code generation on iOS, so some language features are not available. Android – C# is compiled to IL and packaged with MonoVM + JIT’ing. Unused classes in the framework are stripped out during linking. The application runs side-by-side with Java/ART (Android runtime) and interacts with the native types via JNI. Windows – C# is compiled to IL and executed by the built-in runtime, and does not require Xamarin tools. Designing Windows applications following Xamarin’s guidance makes it simpler to re-use the code on iOS and Android. Note that the Universal Windows Platform also has a .NET Native option which behaves similarly to Xamarin.iOS' AOT compilation.

You still need to be an iOS/Android dev, Xamarin only provides a different language and a few different core APIs, but you have to know how each platform works. Shared code varies by project, a Xamarin Forms might share "90%" of the code but is very limited in the UI area. In my experience a regular project might share around 30%, the other 70% is usually UI and API calls of each platform. For basic apps might work, but if you try to push the envelope you will face compatibility and stability issues per platform. Xamarin introduces its own set of problems, again compatibility and stability are regular issues.

You have to bind any "unpopular" and even some "popular" native libraries by yourself to be able to use them in your project. Android supports lags behind, iOS is usually on time. Android development is slower and clumsier. You will have more luck using their forums than looking for answers in stackoverflow. Xamarin Studio crash and burns just because.

We can use the Device.RuntimePlatform enumeration to check for the platform as below:

if (Device.RuntimePlatform == Device.iOS)
{
  //Call the iOS Specific Method here
}

Using MessagingCenter , we can enable our ViewModel s or other components of our application to communicate with each other, without knowing anything about each other. Thus it decouples senders and receivers from each other. It is just a simple messaging contract, where receiving object has to Subscribe or Unsubscribe the Message sent by the Sender . Example: Suppose we want to edit some detail in one Page , and want to notify the other Pages about this update, then we can send Message and other Pages, which have subscribed for this Message , will receive the notification via this Message and thus we can take appropriate actions in other Pages based on it.

There are four ways we can bind the data to the BindableObject .

1. Default : When we use the Default Binding mode, it indicated that as OneWay binding, means, data change propagates from source ( ViewModel in this case) to View element.
2. OneWay : It reflects the change from source to View element as mentioned above. Example: Label uses OneWay binding.
3. OneWayToSource : It reflects the changes from target ( BindableObject ) to source ( ViewModel ). This is basically used for the readonly Bindable Properties.
4. TwoWay : It reflects the changes between source and target in both directions. Example: Entry generally uses the TwoWay binding.

Yes, we can customize the ViewModel initialization in the XAML's backend .cs file. Suppose, we want to initialize it with some dynamic data. So if your page requires some dynamic data passed into the page before it gets loaded, you need to pass it into ViewModel 's parameterized constructor. Now assign this instance of ViewModel to the BindingContext of a Page in the backend .cs file. Thus, it helps us in constructing the ViewModel with some data. public partial class HomePage : ContentPage

{
  public HomePage(int userId)
  {
    //Ex. I want to pass the logged in user id into HomeViewModel then,
    BindingContext = new HomeViewModel(userId);
    InitializeComponent();
  }
}

Xamarin.Forms provides Device.Idiom enumeration through which we can tweak the design/layout/functionality between Phone & Tablet. TargetIdiom enum provides following values to differentiate among various devices: Phone, Tablet, Desktop, TV, Unsupported. Consider:

<Grid VerticalOptions="FillAndExpand">
<Grid.ColumnSpacing>
<OnIdiom x:TypeArguments="x:Double" Phone="20" Tablet="40"/>
</Grid.ColumnSpacing>
<Grid.Padding>
<OnIdiom x:TypeArguments="Thickness" Phone="10, 10, 10, 0" Tablet="20, 20, 20, 0"/>
</Grid.Padding>
<!-- Grid Content -->
</Grid>//In Code:
if (Device.Idiom == TargetIdiom.Phone) {
  // layout views vertically
} else {
  // layout views horizontally tablet or desktop
}

Using Effects, we can customize the native controls on each platforms. Same can be achieved using Custom Renderers, but sometimes it is recommended to use Effects instead of Custom Renderers. Effects is recommended when there is a small style change for a control. However, using Custom Renderer can be heavy for this small change. Implementing Effects is simpler and reusable rather than Custom Renderers. Effects can be parametrized, to make it more reusable.

Xamarin.Forms implements DataTemplateSelector (introduced in Xamarin.Forms V 2.1), which provides a way to customize the presentation of a Cell at Runtime. For example, if we want to create a ListView which displays the chat messages, then we display incoming message to the Left and outgoing messages to the Right along with different colors. We can achieve this using the DataTemplateSelector . We have to override the DataTemplateSelector class and design different DataTemplate s for Incoming and Outgoing messages and then, at runtime, we can decide which one to select for the ListView item based on the bound data.

Built in cell actually allows us to show some data into the List for some simple scenarios. But, in some real world scenarios, these simple cells can't fulfill all our needs. For example, let's say we want to show few labels, 2 buttons, and one image to the right side of the cell. This scenario can't be accomplished using built-in cells. So, we have to go for some customization. In the ListView 's DataTemplate , we can simply wrap our own set of controls in ViewCell Tag. Consider:

<ListView RowHeight="60">
<ListView.ItemTemplate>
<DataTemplate>
<ViewCell>
<StackLayout Orientation="Horizontal" HorizontalOptions="Fill">
<StackLayout Orientation="Vertical">
<Label Text = "{Binding Name}" />
<Label Text = "{Binding Email}" />
</StackLayout>
<Image Source="{Binding ProfileImage}" HorizontalOptions="End" />
<Button Text="Delete" WidthRequest="100" HeightRequest="50" />
</StackLayout>
</ViewCell>
</DataTemplate>
</ListView.ItemTemplate>
</ListView>

Don't create UI in code behind. Use XAML for it because XAML is more readable then code. Avoid using a RelativeLayout . It asks CPU to perform significantly more work. Enable the XAML Compiler. It performs compile time checking of XAML for any errors and removes some of the load. Use correct layout to achieve desired UI. Don't use StackLayout if the same can be achieved by using Grid . Grid is more lightweight then StackLayout . Use Layout Compression to improve the Page rendering performance. Don't use Binding when there is no need to. Example: if Button title is not dynamic, then give it statically in XAML itself. Don't set the VerticalOptions and HorizontalOptions properties of a layout unless required. Always try to reduce the Visual Tree Size. Reduce the Application Resource Dictionary Size.

You can not achieve performance like native application. There are some dependencies like Xamarin compiles C# to native code, but still relies on the Mono runtime to do a lot of its work. The apps are going to be larger – this minor stuff matters when you are trying to get the max oomph out of your very resource restrictive mobile device. You still need a Mac for iOS A huge emphasis on better app patterns like MVC or MVVM, because user interface is still native. You can write about 70% reusable code using Xamarin, but the last 30% or more depending upon your app design and nature, has to be native. I’ve had better luck finding support and code samples for native, than for Xamarin.

Unlike Android, iOS does not allow users to directly install third-party apps. Only those apps that are signed by Apple can only be installed by the iOS users. The provisioning profile is a link between the Developer of the app (his Developer Account) and the Device on which it is being used. The provisioning profile is downloaded from the developer account and the entire bundle is code-signed by the iOS. A Development Provisioning Profile must be installed on each device on which the developer wishes to run his application. If the information in the provisioning profile doesn't match certain criteria, the app won't launch.

The registrar is code that exposes managed code to Objective-C. It does this by creating a list of every managed class that derives from NSObject: For all classes that are not wrapping an existing Objective-C class, it creates a new Objective-C class with Objective-C members mirroring all the managed members that have an [Export] attribute. In the implementations for each Objective–C member, code is added automatically to call the mirrored managed member.

Xamarin.iOS applications run within the Mono execution environment, and use full Ahead of Time (AOT) compilation to compile C# code to ARM assembly language. This runs side-by-side with the Objective-C Runtime. Both runtime environments run on top of a UNIX-like kernel, specifically XNU, and expose various APIs to the user code allowing developers to access the underlying native or managed system. The Objective-C language is based upon selectors. A selector is a message which is sent to an object or class. With Objective-C this is done via the objc_msgSend functions. Xamarin.iOS maps instance selectors to instance methods, and class selectors to static methods.

When you compile any Xamarin platform application, the Mono C# (or F#) compiler will run and will compile your C# and F# code into Microsoft Intermediate Language (MSIL). If you are running a Xamarin.Android, a Xamarin.Mac application, or even a Xamarin.iOS application on the simulator, the .NET Common Language

Runtime (CLR) compiles the MSIL using a Just in Time (JIT) compiler. At runtime this is compiled into a native

code, which can run on the correct architecture for your application. But, there is a security restriction on iOS, set by Apple, which disallows the execution of dynamically generated code on a device. To ensure that we adhere to these safety protocols, Xamarin.iOS instead uses an Ahead of Time (AOT) compiler to compile the managed code. This produces a native iOS binary, optionally optimized with LLVM for devices, that can be deployed on Apple’s ARM-based processor.

Xamarin.Android applications compile from C# into Intermediate Language (IL) which is then Just-in-Time (JIT) compiled to a native assembly when the application launches. Xamarin.Android applications run within the Mono

execution environment, side by side with the Android Runtime (ART) virtual machine. Xamarin provides .NET bindings to the Android.* and Java.* namespaces. The Mono execution environment calls into these namespaces via Managed Callable Wrappers (MCW) and provides Android Callable Wrappers (ACW) to the ART, allowing both environments to invoke code in each other.

**Android Callable Wrappers (ACWs) **are required whenever the Android runtime invokes managed code. These
wrappers are required because there is no way to register classes with ART (the Android runtime) at

runtime.Android Callable Wrappers thus make up for the lack of runtime type registration support. Every time Android code needs to execute a virtual or interface method that is overridden or implemented in managed code, Xamarin.Android must provide a Java proxy so that this method is dispatched to the appropriate managed type. These Java proxy types are Java code that has the "same" base class and Java interface list as the managed type, implementing the same constructors and declaring any overridden base class and interface methods. Android callable wrappers are generated by the monodroid.exe program during the build process.

Limited Generics Support - Unlike traditional Mono/.NET, code on the iPhone is statically compiled ahead of time instead of being compiled on demand by a JIT compiler. Mono's Full AOT technology has a few limitations with respect to generics, these are caused because not every possible generic instantiation can be determined up front at compile time. No Dynamic Code Generation - Since the iOS kernel prevents an application from generating code dynamically, Xamarin.iOS does not support any form of dynamic code generation like The System.Reflection.Emit is not available, no support for System.Runtime.Remotin and so on. No Remoting - The Remoting stack is not available on Xamarin.iOS. Runtime Disabled Features - like Profiler, Reflection.Emit, COM bindings, The JIT engine .NET API Limitations - The .NET API exposed is a subset of the full framework as not everything is available in iOS. In particular, the API profile used by Xamarin.iOS does not include System.Configuration, so it is not possible to use external XML files to configure the behavior of the runtime.

Xamarin applications use a linker to reduce the size of the application.The linker employes static analysis of your application to determine which assemblies are actually used, which types are actually used, and which members are actually used. The linker then behaves like a garbage collector, continually looking for the

assemblies, types, and members that are referenced until the entire closure of referenced assemblies, types, and members is found. Then everything outside of this closure is discarded. Linking is based on static analysis. Consequently, anything that depends upon the runtime environment won't be detected. As the linker is a static tool, it can not mark for inclusion types and methods that are called through reflection, or dynamically instantiated.

Events makes a strong coupling between objects, means Sender and Receiver have to know about each other. Due to this coupling, sometimes, resources doesn't get freed up from memory, and we have to unsubscribe events to free up the resources properly. MessagingCenter decouples objects and thus there is no such dependency among objects and so they get freed up when no longer required. But using too much of MessagingCenter can make it harder for developers to understand who sent it and when they sent it, making it hard to debug the code too. So, we should use them wisely.

Yes, but we can pass static values only. We can use x:Arguments attribute. Example: <ContentPage.BindingContext> vm:HomeViewModel <x:Arguments> <x:Int32 >1234</x:Int32>

//This is passed as a static value as an argument
//to the parametrized construction of ViewModel in XAML.
</x:Arguments>
</vm:HomeViewModel>
</ContentPage.BindingContext>
public class HomeViewModel : BaseViewModel
{
  //Parametrized initialization of viewmodel
  public HomeViewModel(int employeeId)
  {
    //Here you will get 1234 value in the employeeId parameter.
  }
}

This requires that the ViewModel constructor parameters matches with the Type and number of arguments provided in XAML.

Do not put ListView inside ScrollView because ListView has its own Scrollview . Try to use built-in cells like TextCell , EntryCell , ImageCell , SwitchCell instead of creating custom ViewCell whenever possible. Reduce the usage of Cell.ForceUpdateSize method. It will degrade the performance. Avoid changing the cell layout based on BindingContext . Avoid deeply nested layouts. Use AbsoluteLayout or Grid . Avoid Specific LayoutOption s other than Fill . If your cell contains complex UI, then use custom renderers.

Xamarin.Forms is used when: Less platform-specific code is required Code sharing is more important than custom UI UI is not complex Xamarin Native is used when: Lot of platform specific code is required Custom UI is more important then code sharing Many platform-specific APIs are used

Xamarin.Forms is a Cross-Platform Toolkit which helps share Business Logic as well as UI using XAML across all supported platforms. It uses MVVM pattern along with Binding into the XAML UI to accomplish this. It produces pure native controls for each individual platforms. Using Xamarin.Forms, we can share the whole business logic as well as UI among all supporting platforms like iOS, Android and UWP. It also provides a way for platform specific customization of any

native controls using Renderers. Thus, we can almost share about 80-90% of code across platforms. We can say Xamarin is the King of Cross Platforms.

C# & F#

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.

App.cs is the main class of the app which offers features like: MainPage: It helps to set the initial page for the app. Properties Dictionary: It helps us store simple values across lifecycle states. Static Current Property: It gives the instance of the current application object.

Lifecycle methods are set of methods which get executed when application enters into a specific state. Following are such methods: OnStart : Executes when application starts from the beginning OnSleep : Executes each time when application goes into the background

OnResume : Executes when application comes into the foreground from the Sleeping state

On some button click event of First Page, we can call the following method, which will navigate to the second page:

await Navigation.PushAsync (new MySecondPageXaml (), true);
We have to use the " Navigation " property which is available under ContentPage class (XAML Page's code
behind). So this navigation can be written in the Page's code behind file.

Frame : It contains a single element as a child having a default padding of 20. Grid : It is used when UI components are to be arranged into Rows & Columns. StackLayout : It is used when UI components are to be arranged either horizontally or vertically. ScrollView : It enables the scrolling for a child element if required. It has one child only. There are other Layout Controls too like AbsoluteLayout , RelativeLayout , ContentView , ContentPresenter , etc.

Pages are Xamarin Forms generic representation of Cross Mobil Application Screens. A Page occupies most or all of a screen and contains a single child. On IOS, the Page is mapped to ViewController, on Android, it is mapped to somewhat like Activity and on Universal Windows Platform, it is mapped to Page. Pages can be of several types, viz. Master /Detail Page, navigational Page, Carousel Page, Tabbed Page, Template Page, etc.

Margin property represents the distance between the element and its adjacent elements and is used to control the element's rendering position, and the rendering position of its neighbors. Margin can be specified

on Layout and View classes. Padding property represents the distance between an Element and the child elements of it and thus it is used to separate the control from its own content. Padding values can be specified on Layout classes. Suppose, two adjacent elements have a margin of value 20 pixels assigned, what will be the distance between these two elements? Why? The distance between two elements will be 40 pixels in this case, because, Margin property values are Additive . In addition to this, if Margin and Padding both are applied, then the distance between element and its content will be Margin + Padding .

Xamarin.Forms's Application class exposes the Application.Current.Properties Dictionary which is used to store the simple Key-Value pair data. The Properties dictionary uses a string key and stores an object value.

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.

We can use WebView control to display static HTML string . WebView can be used to display Websites, HTML string, Documents, Local Files depending on the platform support.

The ListView and TableView controls are so similar, you can think of them as a single control. The major difference between the two is the manner in which they lay out their items, and it’s easy to change the layout so each control emulates the other. The ListView control displays its data stacked vertically, much like a standard listbox. Use this control to display an ordered list of data, especially long lists that require scrolling like a list of email messages, a list of contacts, or search results. The TableView control displays its data stacked horizontally in rows (although you can alter this behavior and have it displayed in columns first, as well). You use this control when you need more space for rich visualization of each item to be displayed. One of the big differences is ListView provides you a ItemsSource and a Itemtemplate and TableView does not. So items must be added as children manually.