Chapter 7. Deploying and Testing on Devices

Deploying to devices is both important and somewhat a hassle when you try it the first time. Certain issues will only happen on a mobile device, and cannot be reproduced in the iOS simulator or Android emulator. You can also test things that are only possible on real devices such as GPS, camera, memory limitations, or cellular network connectivity. There are also a few common pitfalls that exist when developing for Xamarin, which will only surface when testing on a physical device.

In this chapter, we will cover:

• iOS provisioning

• Android device settings for debugging

• The linker

• Ahead-of-time (AOT) compilation

• Common memory pitfalls with Xamarin

Before we begin this chapter, it is important to note that a valid iTunes account or iOS Developer Program membership is required to deploy to iOS devices. Feel free to go back to Chapter 1, Xamarin Setup, to walk through that process.

iOS provisioning

Apple has a strict process for deploying applications to iOS devices. While being quite convoluted and sometimes painful for developers, Apple can enable a certain level of security by preventing the average user from sideloading potentially malicious applications.

Before we can deploy our application to an iOS device, there are a few things we will need to set up in the iOS Dev Center. We will begin by creating an App ID or bundle ID for your account. This is the primary identifier for any iOS application.

Begin by navigating to http://developer.apple.com/account and perform the following steps:

1. Sign in with your developer account.

2. Click on Certificates, IDs, & Profiles on the right-hand-side navigation.

3. Click on App IDs.

4. Click on the plus button to add a new iOS App ID.

5. In the Name field, enter something meaningful, such as YourCompanyNameWildcard.

6. Select the Wildcard App ID radio button.

7. In the Bundle ID field, select a reverse domain styled name for your company, such as...

Android device settings

Compared to the hassle of deploying your application on iOS devices, Android is a breeze. To deploy an application to a device, you merely have to set a few settings on the device. This is due to Android's openness in comparison to iOS. Android device debugging is turned off for most users, but it can be easily turned on by any user that wishes to have a try at writing Android applications.

Begin by opening the Settings application. You may have to locate this by looking through all the applications on the device, as follows:

1. Scroll down and click on the section labeled Developer options.

2. In the action bar at the top, you may have to toggle a switch to the ON position. This varies on each device.

3. Scroll down and check USB Debugging.

4. A warning confirmation will appear; click on OK.

Tip

Note that some newer Android devices have made it a little more difficult for the average user to turn on USB debugging. You have to click on the Developer options item seven times to turn...

Understanding the linker

To keep Xamarin applications small and lightweight for mobile devices, Xamarin has created a feature for their compiler called the linker. Its main purpose is to strip unused code out of the core Mono assemblies (such as System.dll) and platform-specific assemblies (Mono.Android.dll and Xamarin.iOS.dll); however, it can also give you the same benefits if set up to run on your own assemblies. Without running the linker, the entire Mono framework can be around 30 megabytes. This is why linking is enabled by default in device builds, which enables you to keep your applications small.

The linker uses static analysis to work through the various code paths in an assembly. If it determines that a method or class is never used, it removes the unused code from that assembly. This can be a time-consuming process, so builds running in the simulator skip this step by default.

Xamarin applications have the following three main settings for the linker:

• Don't Link: In this, the linker...

Understanding AOT compilation

The runtime behind Mono and .NET on Windows is based on a just-in-time (JIT) compiler. C# and other .NET languages are compiled into Microsoft intermediate language (MSIL). At runtime, MSIL is compiled into a native code (just in time) to run on whatever type of architecture is running your application. Xamarin.Android follows this exact pattern. However, due to Apple's restrictions on dynamically generated code, a just-in-time (JIT) compiler is not allowed on iOS.

To work around this restriction, Xamarin has developed a new option called ahead-of-time (AOT) compilation, in which your C# code is compiled into native, platform-specific machine code. In addition to making .NET possible on iOS, AOT has other benefits, such as a shorter startup time and potentially better performance.

AOT also has some limitations that are generally related to C# generics. To compile an assembly ahead of time, the compiler will need to run some static analysis against your code to...

Avoiding common memory pitfalls

Memory on mobile devices is certainly not an unlimited commodity. Because of this, memory usage in your application can be much more important than on desktop applications. At times, you might find the need to use a memory profiler or improve your code to use memory more efficiently.

The following are the most common memory pitfalls:

• The garbage collector (GC) is unable to collect large objects fast enough to keep up with your application

• Your code inadvertently causes a memory leak

• A C# object is garbage collected, but is later attempted to be used by native code

Let's take a look at the first problem, where the GC cannot keep up. Let's say we have a Xamarin.iOS application with a button for sharing an image on Twitter, as follows:

twitterShare.TouchUpInside += (sender, e) => 
{ 
  var image = UImage.FromFile("YourLargeImage.png"); 
  //Share to Twitter 
}; 

Now let's assume the image is a 10 MB image from the user's camera roll. If...

Summary

In this chapter, we started out learning the process of setting up iOS provision profiles to deploy to iOS devices. Next, we looked at the required device settings for deploying your application to an Android device. We discovered the Xamarin linker, and how it can make your applications smaller and more performant. We went over the various settings for resolving problems caused by your code and the linker, and we explained AOT compilation on iOS and the limitations that occur. Finally, we covered the most common memory pitfalls that can occur with Xamarin applications.

Testing your Xamarin application on mobile devices is important for various reasons. Some bugs are only displayed on the device due to the platform limitations that Xamarin has to work around. Your PC is much more powerful, so you will see different performance using the simulator compared to on a physical device. In the next chapter, we'll create a real web service using Windows Azure to drive our XamChat application...