SolTech's Technical Architect, Andy, presents Getting started with Xamarin Forms during our weekly Lunch and Learn series

1. GETTING STARTED WITH
XAMARIN FORMS
Writing native mobile apps using our C# skills

2. 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

3. 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!)

4. 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

5. DEMO: GETTING TO KNOW YOU
Creating our first Visual Studio project

6. 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/

7. DEMO: USING XAML FOR YOUR UI
Creating a simple XAML form

8. 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!

9. 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.)

10. DEMO: ADDING A VIEWMODEL
Using a UI-independent object to manage state

11. 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!

12. 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.)

13. 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

14. DEMO: UNIT TESTING OUR
VIEWMODEL
Building a set of xUnit tests for our ViewModel

15. 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

16. 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)

17. QUESTIONS?