Skip to content

Wolf Programmer Posts

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.