GETTING STARTED WITH

XAMARIN FORMSWriting native mobile apps using our C# skills

What is this Xamarin thing?

• Brings the .NET Framework to mobile devices

• Based upon Mono, an open source .NET runtime

• Supports Android, iOS, Windows Phone, OSX

• Supports the latest version of C# (5.0, including async/await)

• Supports development in VS2012/13 but also includes their own IDE (Xamarin Studio)

• Uses the native APIs/UI widgets

• With every release of an API/OS level, the Xamarin team ensures that there’s a managed

wrapper

• Kept current (supported iOS8 on day 1, already includes Android L)

• It’s a commercial product

• Free (Starter) edition is very limited

• 30-day trial available for testing/proof-of-concept work

Why should I be interested in Xamarin?

• Allows us to write in one language (C#) for all platforms

• Android uses Java

• iOS uses Objective C

• Windows Phone uses C#

• But wait: isn’t PhoneGap one language?

• Most C# developers aren’t familiar enough with Javascript to write non-trivial apps

• Javascript can be hard to debug (see: Chris’ talk)

• WebView-hosted Javascript can be even harder to debug

• Extensions (aka Plugins) must be written in the native languages

• HTML is not a native UI

Write once, run everywhere!(no, really!)

Aha! But I still have to learn the platform’s UI!

• Enter Xamarin Forms

• Rather than requiring you to learn three different ways to express your UI, learn one: XAML

• Reasonable level of component support (this *is* a 1.0…)

• Uses a language we’re already reasonably familiar with (XML + syntax extensions)

• Native API support means you still have access to the low-level UI

components if/when you need them

• Can compose new controls from sets of existing controls

• Can modify the look/feel of existing controls

• Can build entirely new controls with native Renderers

• Can mix and match Forms and low-level in the same application

DEMO: GETTING TO KNOW YOUCreating our first Visual Studio project

Extensible Application Markup Language (XAML)

• A way to express application UI layout in XML

• Started out as a feature of WPF

• Supports a high degree of composition

• Turned out to be quite useful

• Xamarin’s XAML dialect isn’t the same as WPF/Silverlight

• It’s pretty similar; the learning curve is short if you’re already familiar with WPF/Silverlight

• Doesn’t have the same feature set (e.g.: styles, behaviors not available yet)

• Continually growing

• http://developer.xamarin.com/guides/cross-platform/xamarin-forms/controls/views/

DEMO: USING XAML FOR YOUR UICreating a simple XAML form

Binding

• XAML supports data and command binding

• This is huge!

• Not every in-box control supports it, though

• Can specify one-way, two-way directional binding

• Syntax is an extension of XML• <SomeControl SomeValue="{Binding PropertyName}"/>

• Applies to properties and events (via commands)

• Allows separation of Presentation and Behavior

• Declare your UI completely in XAML

• Have all logic live in code

• This is different from code-behind!

The Model-View-ViewModel (MVVM) Pattern

• Model

• Your data; typically objects retrieved from Web services, databases, etc.

• Should contain just the state and any data validation code

• View

• Your presentation layer

• Has no awareness of data classes; relies completely on binding for input/output/interaction

• ViewModel

• The “meat” of the application – contains interaction logic, fetch/save calls, any

transformation from data-to-UI structures

• Inherits INotifyPropertyChanged for property change notification to the view

• Exposes ICommand properties for Command objects

• Several prebuilt frameworks (MVVMLight, MVVMCross, etc.)

DEMO: ADDING A VIEWMODELUsing a UI-independent object to manage state

A Recipe for Successful MVVM

• Use bindings for everything

• The UI should be dumb as a post; have all logic in the ViewModel

• Any code in the form’s codebehind should be UI-specific (layout, behaviors)

• Have the ViewModel supply everything the view needs

• No data fetching (e.g. drop-down lists) in the UI; expose a property from the VM

• “Ready” pattern – bind IsVisible/IsEnabled to a “Ready” property

• INotifyPropertyChanged

• The ViewModel should either implement INotifyPropertyChanged or (even better) use a

framework like MVVMLight & ViewModelBase

• Whenever a property changes, fire PropertyChanged

• Be careful when the model is complex; you may need to fire PropertyChanged for multiple

properties from one change!

Why should you take on the overhead of MVVM?

• Supports multiple views with the same logic

• Settings, user profile

• Different layouts by orientation

• Supports a designer/developer workflow

• Designer works on layout/themes, developer works on logic

• To be perfectly honest, we’re not quite there yet

• Testing!

• Code-behind means you can’t test logic without loading the UI

• Unit tests of ViewModels can verify logic without having to know layout

• You can use mock objects to simulate behaviors that are hard to duplicate when running the

app (network failures, service errors, etc.)

ViewModel + Unit Tests = BFF!!!

• Efficient develop/test/debug cycle

• You can now verify behavior without having to run the app and manually enter data

• You can run a suite of tests with every build

• Interfaces + Dependency Injection + Mocks

• Allows you to get very far without needing an actual service

• Edge-case/validation tests

• Fault injection tests

• Gives us a warm sense of security!

• A lot less head-scratching if something fails at runtime

• A much better indication of whether changes broke something

DEMO: UNIT TESTING OUR

VIEWMODELBuilding a set of xUnit tests for our ViewModel

Unit Testing Rules of Thumb

• Design for Testability

• Use interfaces for any services you use

• Separate interfaces and data contracts from implementation

• Use dependency injection to get references at runtime

• Choose a portable framework

• NUnit

• XUnit

• NOT MSTest

• Unit test failures should break the build

• Code coverage is nice, but there be dragons

How can I get started?

• Request a trial license from Xamarin

• You may want to use a VM for this…

• Business Edition required for Visual Studio support

• $1000/platform (!)

• Purchase an “Indie” license

• $30/month (again, per platform)

• Have to use Xamarin Studio

• Publishing apps requires a bit more…

• Apple Developer program is $100/yr.

• Google Play registration is $25 (one-time)

QUESTIONS?