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
2. Hi, I’m Gill!
Gill Cleeren
MVP and Regional Director
.NET Architect @ Ordina
Trainer & speaker
@gillcleeren
gill@snowball.be
3. 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?
5. What is Xamarin?
• Xamarin enables developers to reach all major mobile platforms!
• Native User Interface
• Native Performance
• Shared Code Across Platforms
• C# & .NET Framework
6. 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
7. Advantages of using Xamarin
• Full control
• Familiar development environment
• Native controls
• Native performance
• Code reuse
• Active component store
8. 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
10. Silo’d Approach
Build Apps Multiple Times
• Multiple Teams
• Multiple Code Bases
• Different toolsets
11. Write Once, Run Anywhere Approach
• Lowest common denominator
• Browser fragmentation
• Developing & designing for 1
platform, happen to get other
platforms
Black Box
12. Xamarin’s Unique Approach
• Native User Interface
• Native Performance
• Shared code across
platforms
• C# & .NET Framework
• Full API Coverage
20. Write Everything in C#
iOS, Android, Windows, Windows Phone, Mac
2.5+ Billion Devices!
21. 100% API Coverage
Anything you can do in Objective-C or Java can
be done in C# and Visual Studio with Xamarin!
22. 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
23. 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
26. 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
27. Statistics from Xamarin for some “basic” apps
Components
22%
Services
18%
Android, 12, 12%
Shared
24%
iOS
14%
Windows Phone
10%
Code
Components
Services
Shared
Windows Phone
iOS
Android
28. Code sharing options
• The ultimate goal is reaching an architecture as shown below
• A layered architecture will help us here!
29. 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
30. 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
32. 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
33. Platform divergence:
Dealing with multiple platforms
• On the other hand, some are platform-specific
• Screen sizes
• Navigation metaphors
• Keyboard
• Touch
• Gestures
• Push notifications
34. 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)
35. 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
36. 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
37. Using precompiler statements
public static string DatabaseFilePath {
get {
var filename = "MwcDB.db3";
#if SILVERLIGHT
var 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 folder
string libraryPath = Path.Combine (documentsPath, "..", "Library");
#endif
var path = Path.Combine (libraryPath, filename);
#endif
return path;
}
40. 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
41. 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
42. 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
45. 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
46. Selecting the right targets
Only select the targets you need in your application.
This will give you a broader API!
This selects the profile!
47. 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 )
48. 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
49. 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!
50. 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
53. 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
55. 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
57. 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
61. 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
Notes de l'éditeur
Multiple Teams
Multiple Code Bases
Expensive & Slow
Positive = Great apps delivered to user’s platform
Negative = Development hampered by multiple code bases & fragmentation
Unhappy Users
Unhappy Developers
Increase in Abandoned Apps
Limited to what is implemented
UI build natively per platform, leveraging C#
C# + XAML
C# + XML
C# + XIB
One shared app logic code base, iOS, Android, Mac, Windows Phone, Windows Store, Windows
Statically typed so you avoid a pitfall of errors that afflict other languages.
Use LINQ in your Xamarin projects to query, filter and select data from in-memory arrays, or from databases such as SQLite.
Parsing XML is easy
Setting up event handling is a breeze
Intellisense, lambdas, etc. are all awesome.
Use your favorite libraries like Json.NET!
Here is an example of creating an attributed string.
Take advantage of C# features and set properties easily
Here we are looking for the PacketSizeUpperBound, 1 line of code
Here we can see how easy it is just to do a += for an event and not have to implement a bunch of listeners every time. Easy to read, string.Format, using args, etc.
In fact we can make this call Async/Await by just adding async to the delegate!
The async and await keywords in C# 5.0 now available to Xamarin developers make asynchronous programming incredibly pleasant.
You end up with code that is much more linear and much easier to understand.
The compiler does a lot of magic for you which simplifies your code and your life.
Take advantage of everything great about C# and now write code that can be shared across all platforms
iOS
Android,
Mac
Windows (WPF, Store, Phone, ASP.NET, etc)
Xamarin offers 100% API coverage on iOS and Android
If you want to do something specific on a platform it is all available
NFC, iBeacon, WiFi, Bluetooth, you name it the API is available
Xamarin beautiful bindings for every API in Android and iOS
Xamarin applications are built against a subset of the .NET BCL known as the Xamarin Mobile Profile. This profile has been created specifically for mobile applications and packaged in the MonoTouch.dll and Mono.Android.dll (for iOS and Android respectively). This is much like the way Silverlight (and Moonlight) applications are built against the Silverlight/Moonlight .NET Profile. In fact, the Xamarin Mobile profile is equivalent to the Silverlight 4.0 profile with a bunch of BCL classes added back in.
iOS – C# is ahead-of-time (AOT) compiled to ARM assembly language. The .NET framework is included, with unused classes being stripped out during linking to reduce the application size. Apple does not allow runtime code generation on iOS, so some language features are not available (see Xamarin.iOS Limitations ).
ivergence isn’t just a ‘cross-platform’ problem; devices on the ‘same’ platform have different capabilities (especially the wide variety of Android devices that are available). The most obvious and basic is screen size, but other device attributes can vary and require an application to check for certain capabilities and behave differently based on their presence (or absence).
This means all applications need to deal with graceful degradation of functionality, or else present an unattractive, lowest-common-denominator feature set. Xamarin’s deep integration with the native SDKs of each platform allow applications to take advantage of platform-specific functionality, so it makes sense to design apps to use those features.
See the Platform Capabilities documentation for an overview of how the platforms differ in functionality.
Screen sizes – Some platforms (like iOS and Windows Phone) have standardized screen sizes that are relatively simple to target. Android devices have a large variety of screen dimensions, which require more effort to support in your application.
Navigation metaphors – Differ across platforms (eg. hardware ‘back’ button, Panorama UI control) and within platforms (Android 2 and 4, iPhone vs iPad).
Keyboards – Some Android devices have physical keyboards while others only have a software keyboard. Code that detects when a soft-keyboard is obscuring part of the screen needs to sensitive to these differences.
Touch and gestures – Operating system support for gesture recognition varies, especially in older versions of each operating system. Earlier versions of Android have very limited support for touch operations, meaning that supporting older devices may require separate code
Push notifications – There are different capabilities/implementations on each platform (eg. Live Tiles in Windows Phone).
Camera – Functionality differs across devices: some devices don’t have a camera, others have both front- and rear-facing cameras. Some cameras are capable of video recording.
Geo-location & maps – Support for GPS or Wi-Fi location is not present on all devices. Apps also need to cater for the varying levels of accuracy that’s supported by each method.
Accelerometer, gyroscope and compass – These features are often found in only a selection of devices on each platform, so apps almost always need to provide a fallback when the hardware isn’t supported.
Twitter and Facebook – only ‘built-in’ on iOS5 and iOS6 respectively. On earlier versions and other platforms you will need to provide your own authentication functions and interface directly with each services’ API.
Near Field Communications (NFC) – Only on (some) Android phones (at time of writing).
Unlike most other project types a shared project does not have any output (in DLL form), instead the code is compiled into each project that references it. This is illustrated in the diagram below - conceptually the entire contents of the Shared Project is "copied into" each referencing project and compiled as though it was a part of them.
The code in a Shared Project can contain compiler directives that will enable or disable sections of code depending on which application project is using the code, which is suggested by the colored platform boxes in the diagram.
A Shared Project does not get compiled on its own, it exists purely as a grouping of source code files that can be included in other projects. When referenced by another project, the code is effectively compiled as part of that project. Shared Projects cannot reference any other project type (including other Shared Projects).
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. The user interfaces are rendered using the native controls of the target platform, allowing Xamarin.Forms applications to retain the appropriate look and feel for each platform. This guide will provide a quick introduction to Xamarin.Forms and how to get started writing applications with it.
Xamarin.Forms is a framework that allows developers to rapidly create cross platform user interfaces. It provides it's own abstraction for the user interface that will be rendered using native controls on iOS, Android, or Windows Phone. This means that applications can share a large portion of their user interface code and still retain the native look and feel of the target platform.
Solutions created with Xamarin Studio do not include a Windows Phone project. Use Visual Studio to create new Xamarin.Forms solutions that support iOS, Android as well as Windows Phone. Note that while Xamarin Studio does not support the creation of Windows Phone applications they can still be loaded as a part of an existing solution (ie. one that was created with Visual Studio). This allows you to browse your Windows Phone code in Xamarin Studio, even though it cannot be built or deployed.