The logic that drives the view resides in a view-model class named CalculatorViewModel, which in turn relies on a series of helper classes, one of which models an RPN calculator and is named Calculator. The app uses the popular Model-View-ViewModel (MVVM) pattern, so CalculatorPage.xaml contains little more than the XAML definition of the app’s one and only view. (I did use Xamarin Forms’ awesome OnPlatform feature to tweak the UI for individual platforms, but more about that in a moment.) One XAML file – CalculatorPage.xaml, plus the code-behind file – serves all three platforms.
Note that there isn’t a single line of platform-specific code or XAML in this app. But I digress.) Here’s my Xamarin Forms RPN calculator on Windows Phone, Android, and iOS, in that order: (IMHO, a calculator with an equals button isn’t really a calculator it’s a poor imitation of one. When I set out to learn a new platform, I often begin by writing a Reverse Polish Notation (RPN) calculator – which, coincidentally, is the only kind of calculator I can use. For more information on compiling and running iOS apps from Visual Studio, refer to this article on the Xamarin Web site. You’ll also need to configure it to act as a build server for Visual Studio.
And in order to build for iOS and test in an iOS simulator, you’ll need a Mac or MacBook with the Xamarin.iOS tools installed.
In order to build it and run it yourself, you’ll need to download and install Xamarin for Visual Studio. The sample code presented here uses Xamarin Forms 1.3 and was built using preview versions of Microsoft’s Visual Studio 2015. This is the first in a series of posts I have planned to introduce developers – especially developers versed in Microsoft XAML – to Xamarin Forms. It may be an element in XAML, but it’s a native UITextView in iOS, an EditText control in Android, and a TextBox control in Windows Phone. Under the hood, the XAML elements you instantiate or declare render native UI widgets. That XAML can be declarative – angle brackets and element declarations – or it can be imperative, with elements instantiated programmatically and wired together to form visual trees. In Xamarin Forms, you can use XAML to define a UI, and that UI will work on iOS, Android, and Windows Phone. Developers who have written for WPF, Silverlight, Windows, or Windows Phone have a leg up on the competition because Xamarin Forms rely on XAML. In 2014, Xamarin introduced Xamarin.Forms (hereafter referred to as “Xamarin Forms”), which allow UIs to be shared across platforms, too.
Much of the learning curve comes in learning how to build UIs using idioms specific to each platform.
NET find themselves immediately at home in Xamarin because they’re largely insulated from the underlying operating system’s native APIs. Developers who are familiar with Microsoft.
A typical Xamarin app consists of per-platform UIs backed by a shared code base written in C# and compiled into a Portable Class Library (PCL). NET APIs, but also enjoy the ability to invoke native platform APIs when the need arises. Xamarin apps utilize APIs that derive from Microsoft.
With a heritage rooted in Mono, MonoTouch, and Mono for Android, Xamarin allows developers to write mobile apps in C# and compile them into native apps for iOS, Android, Windows Phone, and other popular platforms. Since 2011, Xamarin has offered a compelling solution to developers who write mobile apps but lack the time or wherewithal to port them to all the popular mobile operating systems. You can write the coolest mobile app in the world, but unless it runs on iOS and Android, few people will care. But the rest of the world doesn’t share that love with me. I love writing apps for Windows and Windows Phone.