Practical Xamarin.Forms Introduction

The cross-platform Xamarin toolset is used by developers to share code between versions of apps written multiple platforms including Android, iOS and Windows Phone. In order to further simplify development of simple forms input -driven applications, Xamarin provides a special UI kit – Xamarin.Forms. In the past, we gave a short Xamarin.Forms overview. Today, we want to dive deeper, sharing practical Xamarin.Forms tips.

Xamarin.Forms is implemented above Xamarin.iOS, Xamarin.Android and Xamarin.WinPhone. If your app can be coded using only Xamarin.Forms UI, theoretically it should allow sharing of both application logic and presentation. The same project could be built for and used on multiple platforms, without platform specific customizations.


forms-architecture

The above image illustrates Xamarin.Forms architecture with Portable Class Libraries sitting above Xamarin.iOS, Xamarin.Android and Xamarin for Windows Phone. In a nutshell, Xamarin.Forms is a collection of editors, layout panels, navigation panels etc. In order to display controls, Xamarin utilizes a concept of a renderer. Renderer is essentially a platform-specific implementation of a cross-platform Xamarin.Forms primitive. In turn, platform-specific Xamarin controls are wrappers around native controls. For example, PCL layer’s class Button is backed by ButtonRenderer implemented in Xamarin.Android, Xamarin.iOS and Xamarin.WinPhone. A layer deeper, ButtonRenderer is rendered using a native button control – UIButton on iOS.

While learning Xamarin.Forms, we uncovered various limitations. Let’s review the issues that developers face and the strategies on mitigating some of those issues.

  • One of the first problems that we noticed while working Xamarin.Forms is the incomplete implementation of WPF templates used for defining the visual appearance of the controls.
  • Since platforms and their native controls often significantly differ, renderers have to hide some of the features in order to unify their PCL-level representation. For example, Android text field control can be styled for both single and multi -line appearance, while iOS includes two controls UITextField for single-line input and UITextView for multiline. Since one control is backed by a single renderer, Xamarin.Forms PCL text input control is always multiline.
  • Sometimes, a PCL control looks or behaves differently on each platform. For example, some Windows Phone controls, such as the Switch control have wide margins. On iOS and Android, this issue is not present. Xamarin.Forms apps using such vanilla controls will render quite differently on Android/iOS and WinPhone, which could be a problem – a view with such controls that looks perfectly fine on Android and iOS may simply not fit the screen on Windows Phone.
  • An additional abstraction layer plus aggressive re-drawing/re-rendering of the view with the contained elements makes Xamarin.Forms apps noticeably slower than their native counterparts.

While the above-mentioned problems are indeed real, Xamarin.Forms can be “tuned” to mitigate some the issues. In order to overcome limitations, we will dive into the Xamarin platform. Let us try to deal with the wide margin issue.

We make a test app displaying two switches with the look defined by the below grid.

<Grid RowSpacing=”0″>
   <Grid.RowDefinitions>
       <RowDefinition Height=”Auto” />
       <RowDefinition Height=”Auto” />
   </Grid.RowDefinitions>
   <Switch Grid.Row=”0“ />
   <Switch Grid.Row=“1“ />
</Grid>

On iPhone, our app will render as:

switch_ios

The appearance on Android will be similar, however on Windows Phone the app will look as:

switch_winphone

Windows Phone switch control has a lot wider margins. Since this issue is specific to Windows Phone, we have to solve it at the Windows Phone level. While we could create a new default Windows Phone style with narrow margins, this is not a good solution since the new style would be applied to all WinPhone controls. Instead, we will adjust appearance of the switch by creating a custom switch control renderer where we can tune the visual appearance as necessary.

Control switchControl = VisualTreeHelper.GetChild(Control, 0) as Control;
Border border = VisualTreeHelper.GetChild(switchControl, 0) as Border;
Grid grid = VisualTreeHelper.GetChild(border, 0) as Grid;
grid.Height = 40;

Now, we need to return the correct size.

public override SizeRequest GetDesiredSize(double widthConstraint, double heightConstraint) {
   SizeRequest result = base.GetDesiredSize(widthConstraint, heightConstraint);
   result.Request = new Size(result.Request.Width, 40);
   return result;
}

Now, the margin is slimmed and our app looks as below.

switch_winphone_tuned

Stay tuned for more Xamarin and Xamarin.Forms tips in upcoming posts.

Please follow and like us:

Xamarin.Android Performance Analysis

Ever wondered how Xamarin.Android performance stacks against code written in Java? We did.

As an introduction, let’s refresh Xamarin.Android architecture. While on Apple iOS Xamarin code is compiled into native code, on Android things work differently. Xamarin code runs inside a VM which works side-by-side with Java VM running Dalvik code. Hence, since Xamarin does not need to go through JVM, it could in theory work as quickly as even faster than Java. In reality, Xamarin apps will be larger than Java apps, since there is a need to bundle the Xamarin runtime.

  • Let’s examine overhead of Xamarin runtime. In order to do this, we built a simple “Hello World!” app. The app size is under 2 MB.
  • Startup time for native Java apps is better than for Xamarin. While a small Java application starts almost immediately, our Xamarin app takes a second.
  • Integer and floating multiplication written in Java are about 20% quicker.
  • Operations with collections are almost 10 times faster on Xamarin than on Java, because Java lacks struct value type.
  • String manipulations under Xamarin are about four (4) times faster than code written in Android-native Java.
Please follow and like us:

What we learned from using Xamarin.Forms

According to Xamarin using Xamarin.Forms can increase code-reuse for Android, iOS and Windows from 70% to 90%. 

Cons:

  • Number of available controls is still limited. Some supported controls are missing critical properties. For example, Picker is missing bindable.
  • Some XAML features are missing while others are implemented differently.
  • Documentation is often insufficient, sometimes limited to a list of properties and method signatures.

Pros:

  • Missing controls can sometimes be substituted with third-party plugins.
  • XAML allows specifying platform specific layouts with OnPlatform and OnIdiom.
  • Elegant publisher-subscriber implementation allows loose coupling between platform specific and shared code.
Please follow and like us:

Crossplatform Mobile App development with Xamarin

Now that Microsoft put its’ weight behind cross-platform C# development for Android and iOS with Visual Studio 2015, it makes even more sense to take a look at Xamarin.

Xamarin interacts with iOS and Android platforms via proxy libraries MonoTouch and Mono.Android.

Pros:

  • Crossplatform – Multiplatform support is provided by standard Mono/.NET libraries – System.Data, System.IO, System.Net etc.
  • Xamarin apps run Android, iOS and Windows.
  • Visual Interface Designer- InterfaceBuilder and Visual Studio add-on allow visually designing UI.
  • C# – Developers familiar with C# can build apps suitable for AppStore distribution without having to learn Objective-C or Java.

Cons:

  • Memory Leaks – Most classes implement IDisposable interface and memory leaks are a serious concern. Elements are often proxies to native objects and Dispose it required to memory leakage.
  • Exceptions – While Xamarin throws exceptions such by raising MonoTouch.Foundation.MonoTouchException and Java.Lang.Throwable, yet some exceptions only happen inside framework and never get to the app. Stack overflow, for example, crashes the app without even raising any exceptions.
  • Some native API calls are not supported. For example, MonoTouch.AddressBook.ABPerson.GetVCards is missing. Xamarin.Android does not generate events AnimationStart and AnimationEnd for ViewFlipper.
  • Support – there is a lot more information and help available for native development.

The shortcomings of Xamarin are manageable, but in some instances developers have to be ready to hack the Xamarin platform or engage a consultant to help with topical issues.
If you are planning to develop an app for just one platform, it probably makes sense to stay native, even if it requires learning a new platform.

Please follow and like us: