Skip to content

Month: June 2016

Xamarin.Forms Structure

In the previous blog post, we created a Xamarin.Forms Portable Class Library (PCL) solution. In this blog post, we will discuss the actual file structure of that same solution and deploy it to an actual simulator.

Hello Forms Root Solution StructureAfter creating the solution, you will notice three separate projects (i.e. HelloForms, HelloForms.Droid, and HelloForms.iOS). If you are at all familiar with Xamarin native projects, the structure of the Android and iOS Forms projects are virtually identical to the native. Adversely, you will notice an additional project named HelloForms; this is the PCL.

HelloForms iOS ProjectThe PCL acts as the core of your application and will contain a majority of your code (if this is not the case, you should probably stick with Xamarin native).

Contained within the iOS project, is a file named Main.cs. This file acts as the main entry into your iOS application. Main.cs will simply instantiate our AppDelegate.cs file.

Inside our AppDelegate.cs file is where the Forms magic begins. Forms is first initialized and a new instance of the PCL’s App.cs class is loaded.

HelloForms Android ProjectBefore we discuss the PCL App.cs class, let’s switch over to see how Android launches. Inside the Android project, you will find the MainActivity.cs file. Android simplifies the process by combining the entire launch process into this one file. The MainActivity.cs file both acts as the main entry into the application and also initializes Forms and instantiates the PCL’s App.cs class. Android does not use the MainActivity.cs file as the entry point due to the name, it is used because it contains the “MainLauncher = true” attribute.

HelloForms PCL ProjectBoth platforms have now entered PCL land. If we open the PCL project, we can now look inside the App.cs file… However, an App.cs class does not seem to exist. If you recall from the last blog post, we opted to use XAML to build our UI. Therefore, App.cs is actually called, App.xaml. You will notice that there is an expandable indicator next to the App.xaml file. Once you expand the file, you will see an App.xaml.cs file nested below the App.xaml file. App.xaml.cs is the C# code behind our XAML file. Inside our code behind file, we have a constructor which sets the first page for our application, and the self explanatory OnStart(), OnSleep(), and OnResume() methods. We will use the App.xaml.cs class in later blog posts to accomplish more advanced functionality.

From the App.xaml.cs code behind, we discover that HelloFormsPage() is set as our MainPage. This is simply a template page that was created when we created the solution. We can change this later; however, let’s use it for this example. In Xamarin.Forms, pages are views that occupy the entire screen. This page is essentially the equivalent to a UIViewController’s UIView in iOS or an Activity’s View in Android. Similar to the App.cs file, the HelloFormsPage is made up of both a XAML file and a C# code behind file.

We will go much deeper into XAML in later blog posts; however, just so you can get a taste for it, open the HelloFormsPage.xaml file. You will notice on line 3 that there is a Label. Update the text from “Welcome to Xamarin Forms!” to “Hello Xamarin.Forms” (be careful, the text for this label must be encapsulated in double quotes). Save your changes.

Xamarin Studio Set As Startup ProjectWe are now ready to build and launch our application. Right click on the iOS project, and select “Set As Startup Project”. Xamarin Studio Start Debugging IconYou can now select the build and deploy icon (looks like the play icon you would find on a tv remote).  This will build the application and deploy it to an iOS simulator on your Mac. To stop the application, you can hit the stop icon in Xamarin Studio (same button location as the play icon).

To launch the Android application, right click on the Android project, and select “Set As Startup Project”. Click the play icon (aka Build and Deploy). A default Android emulator should launch.

Android HelloForms App iOS HelloForms App

Congrats on building your first Xamarin.Forms app!

Creating Xamarin.Forms Solution

In this post, we will see how to create a simple Xamarin.Forms application. We will be using Xamarin Studio as our IDE of choice; the initial setup is almost identical using Visual Studio. There is one cavate when determining your developer environment, Mac OS X is required to compile iOS applications and Windows is required to compile Windows applications (thanks Google for playing nice). In a later blog post, I will cover how to add a Windows application to an existing project created on Mac OS X using a Windows virtual machine.

To get started, first open Xamarin Studio on a Mac. From the menu bar, select File > New > Solution. The following dialog will appear. This dialog will allow you to select which project template to use for your solution. Select Multiplatform > App > Forms App and then click Next.

Xamarin Studio New Solution Choose A Template

You will then see another dialog to configure the main settings for your Forms App.

In the App Name textfield, put the name of your application. If the name of the application is more than one word,  Xamarin Studio will add dashes to the complete package name. This can have unintended consequences later on when using advanced features such as intent filtering. My recommendation is to not add any spaces using this dialog and we will fix the display name after the solution has been created (iOS: Open Info.plist > Update Application Name textfield to the desired display name | Android: Right Click on Android Project > Select Android Application > Update Application Name textfield to the desired display name).

In the next textfield, type your organization’s identifier such as a company name. It is customary to prefix the name of your organization with “com.”; the organization identifier and app name will be concatenated to make your applications’ package name (e.g. com.MyCompany.HelloForms).

Next, select which platforms you intend to target. Notice that only Android and iOS are available, this is due to the fact that we are using a Mac. We will add Windows to the solution in a later blog post.

Under the Shared Code section you have the option between using a Portable Class Library (PCL) or a Shared Library. There are pros and cons to using either option. For this example, we will use a PCL since it is the simplest of the two and is the preferred method.

Lastly, you will have the option to use XAML for building your User Interface (UI). This option does not prevent you from using C# to create some or even all your views, it simply indicates your preference. If you are not familiar with XAML, it stands for Extensible Application Markup Language and is an XML based language used to create UIs. XAML is not unique to Xamarin; Microsoft actually developed it and is used with a multitude of technologies such as SilverLight and WPF. For this demo, leave XAML left checked. Then click Next.

Xamarin Studio New Solution Configure Your Forms App

In the final dialog, you will configure your main project settings.

In the Project Name textfield, put the name of your application. This will be used as the name of your PCL project and the prefix to your Android and iOS projects (e.g. HelloForms.Droid and HelloForms.iOS).

In the Solution Name textfield, put the name of your solution. This does not have to match your project name.

Location indicates where on the file system your new solution will be located.

Version Control instantiates a local git repository inside the solution directory. We will not be using git for this demo.

Leave Xamarin Test Cloud unchecked for this demo. Click Next.

Xamarin Studio New Solution Configure Project

We now have a fully functioning application. In the next blog post, we will go over the structure of the solution in detail.

Switching to Xamarin.Forms?

After attending Xamarin Evolve16 this year, Xamarin.Forms appears to have significantly matured since its introduction two years ago. Having only developed using Xamarin.iOS and Xamarin.Android, I had limited exposure to Forms prior to the conference. While at the conference during trainings and conference sessions, it became clear that Xamarin is really pushing the adoption of Forms.

So the question becomes, what is Forms and should I use it? The main business case for using Xamarin is the ability to share as much code between platforms as possible. Xamarin native allows developers to share a majority of their business logic and models, yet you are still stuck having to write a UI for each platform. The most simplistic way I can describe Forms is that it is Xamarin’s attempt to abstract the UI for extensive code sharing and still deliver native (or nearly native) performance and design. Xamarin claims that they were able to share more than 90% of the code for their 2016 Evolve app between Android, iOS, and Windows.

Xamarin Evolve 2016 Android App Code SharingXamarin Evolve 2016 iOS App Code Sharing Xamarin Evolve 2016 Windows App Code Sharing

Images Source

My first impression to this claim was, this sounds too good to be true, so what’s the catch? The catch to using Forms, is that you “lose” the granular control over your UI and the simplicity of platform specific APIs. My previous statement must be qualified because it is not entirely accurate. Before I can explain further, I first have to explain the structure of a Forms application.

Xamarin Forms PCL Solution StructureA Forms solution contains a project for each platform you intend to target. Therefore, you will have a project for Android, iOS, and each flavor of Windows that you decide to support. Also within the solution, you will have an additional project called the PCL or portable class library. Think of the PCL as the core of your application where a majority of all your code lives. Inside the PCL is the Xamarin.Forms NuGet package, which contains all the required libraries to build a Forms application. The primary difference between a native Xamarin app and a Forms app is the PCL. In other words, a Forms app is exactly the same as a native Xamarin app but with additional libraries. This technically means you have access to all the native Xamarin APIs as before (with a catch).

With a rudimentary understanding of the Forms structure, I can now explain my original claim about losing some native control. Since the purpose of using Forms to build your application is to maximize code sharing, this creates complexities when you need to access platform specific features or complete control over your design. While I technically have access to all the native Xamarin APIs, I have to jump through additional hoops in order to utilize them.

The two main approaches to access the native APIs are to use either a custom renderer or a dependency service. A custom renderer allows you to create native UI elements (such as a UIKit.UIView in iOS or a Android.Views.View in Android) for each platform and then integrate them back into a Forms page or view.  A dependency service allows you to access device specific functionality such as the built-in cameras or GPS.

If we have access to all the native APIs, why don’t we always build Xamarin apps using Forms? Two significant reasons why you should weigh your options before making a decision are performance and path of least resistance. Performance is a factor because the entire UI in a Forms application is a compilation of custom renderers contained within the Xamarin.Forms package. This means that there is an additional performance cost to rendering your views. If your application is graphics intensive or uses a large amount of memory, the end users might notice your application not working smoothly. The path of least resistance comes into play depending on the complexity of your application. If your application requires access to a large amount of the native platform APIs and has significant custom UI needs, you will be spending as much if not more time writing custom renders and dependency services as you were attempting to save by sharing more code between platforms. On the other hand, if it is more important to share code between platforms than direct access to the native APIs, Forms is a strong contender. Xamarin provides a quick one page PDF to help you decide which camp your app falls into.

Over the next few months, I will be writing about my experience of porting existing Xamarin.Android and Xamarin.iOS eCommerce apps over to Xamarin.Forms. After evaluating and testing Forms, my team feels that we could benefit from the adoption of Forms. We believe our existing apps fall under the 80/20 rule, 80% of our apps require very little advance custom UIs and platform specific features, while 20% does. Our hope is that the 80% saves us more development time than the 20% of additional overhead. I hope my experience will help others make the right decision for their apps.

HelloWorld( )

As cliche as it is, all developers start out their learning endeavors with a quick HelloWorld(); this blog is no exception. Every successful developer I have met or gained insight from, has encouraged me or those in our profession to start writing a blog. I must freely admit from the onset that I do not particularly enjoy writing or receiving attention, and thus this blog pushes me outside of my comfort zone.

Hi, my name is Thomas Wolf, and I am a software developer in Cheyenne, Wyoming. I have been programming since I purchased my first computer at the age of 12 (thanks paper route). Having access to a computer at such an influential age instilled in me a love for technology. Logically, I then proceeded to receive my bachelors of science degree in computer science. Immediately after graduating, I became a software developer at TJX for a company called Sierra Trading Post. In less than 3 short years of working at Sierra, I have become the lead mobile app and web API developer for the company. I primarily develop using C# and Xamarin.

My intention with this blog is to short circuit the learning process by sharing with others my mistakes and successes. As the old Latin proverb states, “Docendo discimus” meaning “by teaching, we learn.” While I am not, nor will I claim to be the supreme authority on any particular subject, I hope to contribute to the conversation. My goal is to foster a community with other developers and those considering the profession.