c# everywhere: xamarin and cross platform development

Post on 02-Jul-2015

898 Views

Category:

Software

5 Downloads

Preview:

Click to see full reader

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 it

TRANSCRIPT

C# everywhereBuilding cross-platform apps with Xamarin

Gill Cleeren

@gillcleeren

Hi, I’m Gill!

Gill CleerenMVP and Regional Director.NET Architect @ OrdinaTrainer & speaker

@gillcleeren

gill@snowball.be

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

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

top related