Alper Ebicoglu / Volosoft / 2018. Introduction to Xamarin development. Strutcture, platforms, Android, IOS, sharing code, bindings, behaviors, commands.

1. Xamarin
ALPER EBİÇOĞLU / VOLOSOFT / 2018

2. Introduction
 Build C# apps on Android, iOS, Windows, and Mac with Xamarin
 Xamarin is unique in this space by offering a single language – C#, class
library, and runtime that works across all three mobile platforms of iOS,
Android, and Windows Phone (Windows Phone’s native language is already
C#), while still compiling native (non-interpreted) applications that are
performant enough even for demanding games.
https://store.xamarin.com/

4. Hello, Mac
 Xamarin.Mac allows for the development of fully native Mac apps in C# and
.NET using the same OS X libraries and interface controls that are used when
developing in Objective-C and Xcode. Because Xamarin.Mac integrates
directly with Xcode, the developer can use Xcode's Interface Builder to create
an app's User Interfaces (or optionally create them directly in C# code).
 Additionally, since Xamarin.Mac application are written in C# and .NET,
common, backend code can be shared with Xamarin.iOS and Xamarin.Android
mobile apps; all while delivering a native experience on each platform.

5. How Xamarin Works?
 On iOS, Xamarin’s Ahead-of-Time (AOT) Compiler compiles Xamarin.iOS
applications directly to native ARM assembly code. On Android, Xamarin’s
compiler compiles down to Intermediate Language ( IL), which is then Just-in-
Time (JIT) compiled to native assembly when the application launches.
 They’re both built on top of Mono, an open-source version of the .NET
Framework based on the published .NET ECMA standards
 When Xamarin applications are compiled, the result is an Application Package,
either an .app file in iOS, or .apk file in Android. These files are indistinguishable
from application packages built with the platform's default IDEs and are
deployable in the exact same way.

6. Native Performance

7. Platforms
 The Xamarin platform includes Xamarin.Forms, Xamarin.iOS, and Xamarin.Android.
Xamarin.Forms is an all encompassing mechanism for using C# and XAML to write
mobile apps for many platforms, while Xamarin.iOS and Xamarin.Android allow
you to use C# with finer platform touches.
 The Xamarin.Forms allows users to write code in one shared project that will map
to multiple platforms when you compile the application. The actual application
design is centered on the notion of pages which represent individual screens
within the deployed application. Pages use XAML to define the UI (though it can be
done in C# code behind if preferred), and allow for a MVVM approach to
application development where all of the UI is defined in XAML (your view) and
everything data related (which is your view model) in code (C#).
 Reasons to use: familiar C# and Xaml languages, develop for 3 platforms at once (iOS,
Android, and Windows Phone), use Visual Studio or Xamarin Studio as your IDE, develop
UI’s quickly without worrying about platform differences

8. Xamarin.iOS and Xamarin.Android
 The main distinction here is that these allow a higher level of customization.
In a sense they’re almost a step in between Xamarin.Forms and native
development. You still get to use C#, but your project construction starts to
look much closer to the native platforms where items like ViewControllers,
Activities, Storyboards, and the native API’s become much more visible, and
are something the developer is directly interacting with.
 Reasons to use: familiar C# language, create applications with a more
specific look and feel for that platform, develop using Visual Studio or
Xamarin Studio, use Xamarin’s visual designer, you want to invest time more
specifically for one platform.

9. Pure Native Platforms
(iOS and Android)
 The pure native platforms require that you use the language and tools specific to
each platform, but tend to have the best look and feel.
 The native platforms potentially offer the best experience, but often require the
most specific skills. Xamarin goes to great length to ensure that you only need to
know C# and some XAML for markup, but iOS and Android both utilize separate
languages, use their own IDE’s, and require that your project is specifically
targeting their market. There is a large upside to native development though: it
generally has the highest ceiling for performance, it will generally have the most
correct look and feel (though the Xamarin platforms are extremely close), and
allows you to directly use the tools that are made available from the platform
vendor. Some developers may also prefer using XCode, Android Studio, or Eclipse
for development which is something only native development can offer.
 Reasons to use: highest ceiling for performance, potentially best look and feel,
use tools, samples, and documentation directly from Apple or Google, no .NET
background, you're most interested in one platform and you want to know
everything about it.

10. Sharing Code Options
.NET Standard Libraries *Allows you to share code across multiple
projects.*Refactoring operations always update all affected references.*A larger
surface area of the .NET Base Class Library (BCL) is available than PCL profiles.
*Cannot use compiler directives
Portable Class Libraries (DLL) *Allows you to share code
across multiple projects. *Refactoring operations always
update all affected references. *Cannot use compiler
directives. *Only a subset of the .NET framework is
available to use, determined by the profile selected.
Shared Projects (Part of each platform) *Allows you to share code across multiple projects.
*Shared code can be branched based on the platform using compiler directives (eg.
using #if __ANDROID__ ). *Application projects can include platform-specific
references that the shared code can utilize *Unlike most other project types, a
Shared Project has no 'output' assembly. During compilation, the files are treated as
part of the referencing project and compiled into that assembly. If you wish to share
your code as a assembly then Portable Class Libraries or .NET Standard are a better
solution. *Refactorings that affect code inside 'inactive' compiler directives will not
update the code.

11. Project Starting Points
 IOS
 AppDelegate.cs > FinishedLaunching() > LoadApplication(new App());
 Android
 MainActivity.cs > OnCreate() > LoadApplication(new App());
 You can set any activity as startup activity.
 Shared
 App.xaml.cs > OnStart()
 Navigate to any xaml page with MainPage = new NavigationPage(page);
[Activity(Theme = "@style/MyTheme.Splash",
MainLauncher = true,
NoHistory = true)]
public class SplashActivity : AppCompatActivity
{
…
}

12. Symbols
 Allows your shared code files to run platform-specific code or access
platform-specific classes, including classes in the individual platform projects.
You can also define your own conditional compilation symbols if you’d like

13. Application Lifecycle
 The most important is the OnSleep() call. An application goes into
sleep mode when it no longer commands the screen and has become
inactive. Or pressing Home button. Or using application switcher.
 From this sleep mode, an application can be resumed or terminated.
 After the OnSleep(), there is no further notification that an application
is being terminated. The OnSleep() is as close as you get to a
termination notification.
 For example, if your application is running and the user turns off the
phone, the application gets an OnSleep() call as the phone is shutting
down.
 A program that crashes does not get an OnSleep() first but you probably
expect that.
 When you are debugging a Xamarin.Forms application,and use Visual
Studio or Xamarin Studio to stop debugging, the program is terminated
without a preceding OnSleep call.
 Bringing the program back to the foreground and trigger an
OnResume().
 Swiping the application’s image upward on iOS devices or by tapping
the X on the upper-right corner of the application’s image on Android
the program stops executing with no further notification.
 When your program gets an OnResume call, the operating system has
already automatically restored the program contents and state.

14. XAML Structure

15. Markup Extensions
 Allows properties to be set to objects or values that are referenced
indirectly from other sources

16. Data Binding
 Allows properties of two objects to be linked so that a change in one causes
a change in the other

17. MVVM
 The XAML user interface, called the View; the underlying data, called the Model;
and an intermediary between the View and the Model, called the ViewModel.
 ViewModels generally implement the INotifyPropertyChanged interface, which
means that the class fires a PropertyChanged event whenever one of its
properties changes. The data binding mechanism in Xamarin.Forms attaches a
handler to this PropertyChanged event so it can be notified when a property
changes and keep the target updated with the new value.

18. Binding Modes
OneWay Indicates that the binding should only propagate changes
from source (usually the View Model) to target (the
BindableObject). This is the default. It only displays the
value on target.
OneWayToSource Indicates that the binding should only propagate changes
from target (the BindableObject) to source (usually the View
Model). This is mainly used for read-only BindableProperty
values.
TwoWay Indicates that the binding should propagates changes
from source to target in both directions.

19. Command

20. Behaviors
 Behaviors lets you add functionality to user interface controls without having
to subclass them. Behaviors are written in code and added to controls in XAML
or code.
 Adding an email validator to an Entry.
 Creating a rating control using a tap gesture recognizer.
 Controlling an animation.
 Adding an effect to a control.