c# everywhere: xamarin and cross platform development
DESCRIPTION
C# is hotter than ever. Using Xamarin, we can use C# to not only build our apps on Windows Phone but also on iOS and Android. The magic that sits between are PCLs (Portable Class Libraries) that we can re-use on all these platforms. The goal is of course achieving the highest level of code sharing and re-using. In this talk, we'll see how we can share code between Windows Phone, iOS and Android to build a cross-platform app using Xamarin. You'll also see how much of the marketing fluff is real: do we really get a lower time-to-market when sharing code and is this approach really cheaper than building 3 apps separately? Come to this talk and learn all about itTRANSCRIPT
C# everywhereBuilding cross-platform apps with Xamarin
Gill Cleeren
@gillcleeren
Hi, I’m Gill!
Gill CleerenMVP and Regional Director.NET Architect @ OrdinaTrainer & speaker
@gillcleeren
Agenda
• What is Xamarin then? Can I eat it?
• Code re-use: myth or reality?• Shared projects: because sharing is caring, right?
• PCL where L stands for Love?
• And what about Xamarin.Forms?
What is Xamarin then? Can I eat it?
What is Xamarin?
• Xamarin enables developers to reach all major mobile platforms!• Native User Interface
• Native Performance
• Shared Code Across Platforms
• C# & .NET Framework
What is Xamarin?
• Toolset on top of Visual Studio• Output and build to Android, iOS and Windows
• Native apps
• Commercial product• $2000/year for business subscriptions
• The “No-Compromise” approach
Advantages of using Xamarin
• Full control
• Familiar development environment
• Native controls
• Native performance
• Code reuse
• Active component store
Disadvantages of Xamarin
• You need a license
• It’s not a shared UI Platform
• You need to understand each platforms UI controls and UX paradigms
• You need a Mac for iOS dev
The promise: C#. Everywhere.
Silo’d Approach
Build Apps Multiple Times• Multiple Teams
• Multiple Code Bases
• Different toolsets
Write Once, Run Anywhere Approach
• Lowest common denominator
• Browser fragmentation
• Developing & designing for 1 platform, happen to get other platforms
Black Box
Xamarin’s Unique Approach
• Native User Interface
• Native Performance
• Shared code across platforms
• C# & .NET Framework
• Full API Coverage
And where is C# coming into play then?
C# Is AwesomeWe (l) C#. This is why.
• LINQ Support
• Work With XML Easily XDocument
• Event Handling & Delegates
C# Is Awesome – JSON Made EasyWe (l) C#. This is why.
See the Difference – Attributed Strings
C# with XamarinObjective-C
C# is a bit easier than Objective-C. A tiny bit.
C# with XamarinObjective-C
C# is a bit easier than Objective-C. A tiny bit.
C# with XamarinJava
C# & Async with Xamarin
And compared to Java…
Write Beautiful & Maintainable Code
We’ll wait here then.
Write Everything in C#
iOS, Android, Windows, Windows Phone, Mac
2.5+ Billion Devices!
Anything you can do in Objective-C or Java can be done in C# and Visual Studio with Xamarin!
100% API Coverage
Android runtime model
• Mono VM + Java VM execute side-by-side (supports both Dalvik and ART)
• Mono VM JITs IL into native code and executes most of your code
• Can utilize native libraries directly as well as .NET BCL
iOS Runtime model
• Native ARMx code – no JIT is being used here
• Mono runtime provides system services such as Garbage Collection
• Full access to iOS frameworks such as MapKit as well as .NET BCL
DEMOLooking at a complete Xamarin application
Code re-use: myth or reality?
Code sharing in general
• Large chunks of the code we write are shareable between platforms• Data access
• Service access
• Services
• “ViewModels”
• What isn’t shareable by default• View/UI code
• Different situation with Xamarin.Forms…
• Event handlers
• Services bound the platform
Statistics from Xamarin for some “basic” apps
Components22%
Services18%
Shared24%
Windows Phone10%
iOS14%
Android, 12, 12%
Code
Components
Services
Shared
Windows Phone
iOS
Android
Code sharing options
• The ultimate goal is reaching an architecture as shown below• A layered architecture will help us here!
Code sharing options
• Shared projects: • allows organizing the shared code
• #if directives for platform specific code
• PCL• “include” the platforms we want to support
• Abstract to interfaces where platforms have specific implementations
Creating a Xamarin cross-platform solution
• We start from an *.sln file (solution file)
• Make your choice: shared project or PCL• Shared project: simply plugs in the code into each platform, use #if to control
code execution
• PCL: Portable Class Library (PCL) is a special type of project that can be used across disparate CLI platforms such as Xamarin.iOS and Xamarin.Android, as well as Silverlight, WPF, Windows Phone and Xbox
Creating a Xamarin cross-platform solution
Platform divergence:Dealing with multiple platforms• Some concepts are the same on all platforms
• Feature selection via tabs or menus
• Lists of data and scrolling
• Single views of data
• Editing single views of data
• Navigating back
Platform divergence:Dealing with multiple platforms• On the other hand, some are platform-specific
• Screen sizes
• Navigation metaphors
• Keyboard
• Touch
• Gestures
• Push notifications
Platform divergence:Dealing with multiple platforms• And then, some are device-specific
• We’ll need to write code to check if a feature is present or offer an alternative (map for location selection instead of GPS)
• Typical cases:• Camera
• Geo-location
• Accelerometer, gyroscope and compass
• Twitter and Facebook
• Near Field Communications (NFC)
Dealing with divergence:Abstracting platforms• Inheritance/base classes can be created in the shared projects
• Base functionality already created (cross-platform!)• Limited somewhat since C# only allows base single inheritance
• Xamarin.Forms• Uses a common, abstracted base for the UI creation
• Xamarin Mobile augments the .NET Base Class Libraries with a set of APIs that can be used to access device-specific features in a cross-platform way• Media Picker: taking photos or selecting a media item• Geolocation• Address book access• Code can be written in shared code since it’s ignorant (for us) to the used
platform
Dealing with divergence: divergent platform code• Some cases won’t work with just abstraction
• Conditional compile can help out• __MOBILE__ is true for iOS and Android projects
• __IOS__ can be used to detect iOS devices
• __ANDROID__ can be used to detect Android devices
• __ANDROID_XX__ can be used to detect specific Android API version • __ANDROID_11__
• __WINDOWS_PHONE__ and __SILVERLIGHT__ can be used to detect Windows Phone devices
Using precompiler statementspublic static string DatabaseFilePath {
get { var filename = "MwcDB.db3";
#if SILVERLIGHTvar path = filename;
#else
#if __ANDROID__string libraryPath = Environment.GetFolderPath(Environment.SpecialFolder.Personal); ;
#else// we need to put in /Library/ on iOS5.1 to meet Apple's iCloud terms// (they don't want non-user-generated data in Documents)string documentsPath = Environment.GetFolderPath (Environment.SpecialFolder.Personal); // Documents folderstring libraryPath = Path.Combine (documentsPath, "..", "Library");
#endifvar path = Path.Combine (libraryPath, filename);
#endifreturn path;
}
DEMOXamarin.Mobile
Shared projects
Before Shared Projects…
• We could use file linking• Add existing item >> Add as Link
• File isn’t duplicated, instead, it lives in the original location only• When compiling, it is part of the compiled output
• Can include precompiler statements to have different behaviour on different OS’s
• Disadvantage: refactoring not ideal + testing not great
Today: Shared Projects
• AKA Shared Resource Projects• Allow writing code which is shared between multiple target projects incl
Xamarin• New project type makes it possible to share on project-level
• IDE knows this, supports this
• Also supports precompiler statements• Different coloring based on the application
• Only 1 copy of the file exists• Supports testing and refactoring • Supported since XS 5 and VS 2013 Update 2• Also works with Windows Phone 8 and Windows 8.1
Shared Projects internals
• Shared project has no DLL output• Code gets compiled in each project which references it
• Project gets copied into each referencing project
DEMOShared projects
PCLs
What’s a PCL then?
• When creating a regular project, the DLL is restricted to that platform only• By default, a WP8 Class Library won’t work from Xamarin
• A PCL overcomes this: we can choose the platforms we want our code to run on• Choices are the Profile identifier: describes which platforms are supported
• Based on selection, features may/may not be available
Selecting the right targets
Only select the targets you need in your application. This will give you a broader API! This selects the profile!
Missing profiles
• Not all combinations are allowed, simply because they aren’t defined by Microsoft
• IDE will try to select the closest match (or an error if you have done something you shouldn’t )
Advantages of PCLs
• Centralized code sharing – write and test code in a single project that can be consumed by other libraries or applications
• Refactoring operations will affect all code loaded in the solution (the Portable Class Library and the platform-specific projects)
• The PCL project can be easily referenced by other projects in a solution, or the output assembly can be shared for others to reference in their solutions
Disadvantages of PCLs
• Because the same Portable Class Library is shared between multiple applications, platform-specific libraries cannot be referenced (eg. Community.CsharpSqlite.WP7)
• The Portable Class Library subset may not include classes that would otherwise be available in both MonoTouch and Mono for Android (such as DllImport or System.IO.File)
• Using abstractions (DI or Provider pattern) can help circumventing some of these restrictions!
Going around PCL limitations
• PCLs uses the smallest common denominator• All features in the PCL (and the profile) must be available on all targets
• By default, no support for File, SteamReader…
• Solutions: • Rely on what’s there (often lower-level abstractions)
• Build your PCL with abstractions (interface, events…) and implement the abstraction in your platform specific code• Events
• Concrete implementations of interfaces
• IOC
DEMOPCLs
And what with Xamarin.Forms?
So what is Xamarin.Forms really?
• Xamarin.Forms is a cross-platform natively backed UI toolkit abstraction that allows developers to easily create user interfaces that can be shared across Android, iOS, and Windows Phone• Allows rapid development of cross-platform UIs
• Abstraction on top of UI elements
• More code sharing than ever before
• Still native apps
• Still native performance and look and feel
With Xamarin.Forms
With Xamarin.Forms:
more code-sharing, native controls
Shared UI Code
Main features
• RAD, forms-based app creation
• 40+ Pages, Layouts, and Controls• Build from code behind or XAML
• Two-way Data Binding
• Navigation
• Animation API
• Dependency Service
• Messaging Center
• Support for• Android 4.0+• iOS 6.1+• Windows Phone 8.0+ (Silverlight only)
Shared UI Code
Getting started
• Resulting solution:
• Note that XS doesn’t support the WP8 currently• Will open but not load/compile
• Shared Project or PCL holds shared code, used by all other projects
• iOS, Android and WP8 projects contain platform-specific UI code
DEMOCode sharing with Xamarin.Forms
Creating a XAML-based application
• Add a XAML file (ContentPage)• Also creates the code-behind
DEMOXAML-based Xamarin.Forms
Summary
• Xamarin == native cross platform
• Strong backing of shared projects and PCLs help code re-use
• Xamarin.Forms goes the extra mile• Still somewhat limited though