Hey! Good morning everybody. Welcome to Xamarin University Presents: a Desktop Developer's Guide to Mobile
with Visual Studio tools for Xamarin. My goal this morning is to encourage each and every one of you
to take your desktop skills and turn them into mobile skills with Xamarin
but before we get to that, I'd like to introduce myself
my name is Mark Smith and I'm a Program Manager for Microsoft my job
is to direct the technical and business areas of Xamarin University
I'm also a longtime developer primarily in the desktop world, going all the way back to 16-bit Windows
I made the jump to mobile about five years ago when I was asked to simulate a WPF medical
application on the iPad to make it easier for sales to carry around and show people
I bid it pretty low thinking my strong C and C++ background would help me out with learning Objective-C
after a week of research I was sweating it thinking I was about to get paid less than minimum wage for this job
Luckily I stumbled across Xamarin which was then called MonoTouch and I was astonished that I could build the app in C#
I ended up reusing about 75% of the code from the existing app some of it being tweaked and some of it just carried straight over
its saved me months of time and we came in under cost. So I'm here today to show you how you can
make the same transition and either bring some of your apps to new platforms
or just start working on a brand new mobile app with Xamarin
I mentioned that I run Xamarin University and you might be wondering exactly what that is
Xamarin University's mission in life is to teach developers how to build amazing native mobile apps
with C# and we've got tons of resources to engage in that mission
When you sign up for Xamarin University, you get live, interactive mobile development training led by Xamarin experts, offered in all
timezones. You get to interact with talented developers who know the platform better than anyone else.
We have 1:1 sessions to get your questions answered fast. This let you schedule time with Xamarin experts to review your app, get
advice, remove technical roadblocks, and more. This is a huge benefit for our subscribers because you get to interact with our experts
directly, in a focused, open session to move your project forward.
Live classes are awesome, but sometimes you need the training now and can't wait for a scheduled class. Self-guided Learning enables
you to get essential Xamarin training, earning course credits towards certification - at your own pace. These classes include the same
content as live versions and provide on-demand training right when you need it. The best part of our Self-Guided learning
is it's all free – just register for an account and you can go through all of our on-demand content and try a few of the live classes.
Speaking of training, we've got over 80 live and on-demand courses, broken into eight learning tracks
with constantly updated classes, ranging from beginner to expert.
This also includes access to exclusive on-demand videos from industry leaders,
covering the latest mobile topics and challenges, from new platform APIs
to testing and deploying on physical devices.
We have flexible options for subscriptions, including a monthly option starting at $83.25/month. That's less than $3 a day to get
unlimited access to our full course catalog, expert mobile instruction and advice, hands-on help, and more.
Finally, you can work through our courses to become a Xamarin Certified Developer. Our certification program identifies top
mobile developers who complete the certification track coursework and demonstrate practical Xamarin mobile development
expertise. I'm a big fan of Xamarin University and think it has some of the best curriculum and trainers in the industry. If you want to really
learn mobile development, this is the place to do it. It's easy to register or signup – just go to university.xamarin.com to check it out.
We are going to start with a brief introduction to the tools we use for mobile development with C#.
Next we will look at a couple of approaches you can take when building your application user-interface.
Which approach you choose will often depend on what you are familiar with, and the goals you have for the application experience. it out.Œ
Then, we can talk about the transition path – the similarities and differences between a desktop app and a mobile app.
Finally, I want to give you some specific things to think about as you jump onto the mobile bandwagon.
Things I learned which were very important as I started building mobile apps.
We'll end our session with some Q&A, but you can ask questions at any time during this webinar through the chat window. We've got
experts available both during and after the session to make sure you get all your questions answered
Let's start by laying out our ultimate goal.
What we really want is the ability to write applications that can take full advantage of the power, features and performance of each
platform, but write the code in a common language. Or even better, share the code across all of these platforms to reduce
development time and help keep application features and fixes synchronized across all of our supported devices.
And this is where Xamarin comes in - Xamarin is an app-development platform that let's you build applications
applications for iOS, Android and Windows, and share the code across all platforms.
This includes Android phones, iPhones and Windows Mobile, but it also includes other form-factors like
Windows desktop, macOS, wearables, IoT, Xbox and even Hololens.
We can share the code we write across all of these platforms and devices with .NET and the Visual Studio Tools for Xamarin.
With Xamarin, you write your applications in C# using Visual Studio on either Windows or macOS. And its more than just the C# language
you also gain access to the fantastic .NET libraries which provide standard APIs and productivity features such as LINQ and the and
the Task Parallel Framework.
Even better, this also includes many popular 3rd party libraries which are available through NuGet
such as Json.NET and Entity Framework Core. So you can use the same IDE, same language,
and many of the same libraries that you do today.
So if you get anything out of this talk, this is the point I want you to remember. If you are a .NET developer – using Visual Studio to build
applications today you can use the same skills to build native mobile applications
So let's talk about the first steps when creating a new mobile application. The first thing you have to decide
is whether you want to use the native UI or Xamarin.Forms.
The first approach is to use the native UI controls directly.
this approach allows you to easily customize the user experience on a per app basis
and take advantage of all the unique features that the platform offers
Here you write the behavior and business logic of the app in C#, sharing it across all your supported platforms.
And then you build a unique UI definition for each platform using the native controls available on that platform.
This can be done in code, but is most often done using a design tool which works with a dedicated language for the platform.
For example, on
iOS, we use storyboards to craft our UI and on Android, we use XML files with a design surface
And on Windows we will often use XAML with the Blend tool or a design surface for Windows Forms.
This allows all of our core logic to be shared, but the UI definition and code that connects to
it is unique and must be created differently for each platform.
The strength of this approach is that it allows us to craft a unique UI experience for each platform. The downside
is we have to replicate the user interface and experience three times
and if our goal is to make the app look exactly the same on each platform, that's more work for us to do and maintain as the app evolves.
The second approach is to use Xamarin.Forms
Xamarin.Forms abstracts the UI definition to a common set of shared elements
but have it still utilize native, platform-specific controls when it runs. This means we can describe our UI once, either in C#
or XAML, and reuse that definition across all our supported platforms.
That saves us both maintenance and development time, however it also makes it
harder for us to customize the UI on a per-platform basis.
Which approach you decide to use often depends on what you want to build, and how you see it evolving in the future.
Microsoft developers often choose Xamarin.Forms initially because, as you'll see,
the APIs and way you construct the application are very familiar.
However, if you want to have a different user experience on Android than you do on iOS, Xamarin.Forms can be a bit limited and you'll
end up doing a lot more work to get what you want than if you'd just used the native UI approach to begin with.
As we compare these two approaches to what typical Microsoft desktop developers do today,
it's helpful to touch on the history of desktop programming using Microsoft technology.
Lets start back in the 90's when we pretty much worked with VB or C/C++ and Win32 APIs
MFC and VB were all the rage back then and a lot of enterprise apps were built with both of these technologies
than .NET was introduced and we got Windows Forms which is a thin managed wrapper over the Win32
API but included the easy drag and drop approach popularized by VB.
in 2006 .NET 3.0 was released
which included the next generation framework WPF and it's close cousin Silverlight. This was such a radical
departure from Windows Forms that it took years for it to mature and for developers to really learn how to use this framework well.
Enterprises were slow to adopt this technology but it's become one of the most popular ways to build desktop apps today.
2011 was the reinvention of the platform with the introduction of WinRT, a brand new set of
APIs available to .NET to interact with operating system services
Things shifted around here with XAML becoming a system service, and opening up the system to Javascript and C++ developers.
Most importantly, this ushered in a new style of desktop application – sandboxed and full screen
using a new design language to formalize how it should look and feel.
Fast forward to today – the latest desktop framework is the Universal Windows Platform, or UWP.
This is actually not just for desktops for all kinds of devices which run Windows 10.
It is build on top of the WinRT APIs introduced in 2011, but with additional support so that desktop apps
built with UWP act more like we expect them to.
Since I'm only supposed to talk for an hour, I'm going to limit our comparison to the most modern of the desktop frameworks.
This actually makes my job a bit easier because Xamarin.Forms took a lot of design hints from WPF
which makes it similar to most of the Microsoft frameworks introduced after 2006.
However, most of what we talk about applies to Windows Forms as well
it's just that the APIs aren't quite as close and so there will be more effort involved in
reusing code you have build specifically for a desktop Windows Forms application when moving to a mobile application.
So we have a reference of comparison, let's create a brand new Xamarin project and look at what we get.
so let's switch over to Visual Studio
I'm going to create a new project - I can do it right here on the Start Screen.
I can search for project templates and the one I want is Cross Platform Apps (Xamarin)
You can also use File > New Project and then get the same sort of list.
This will just jump me right to where I want in the New Project dialog, which is Visual C# > Cross Platform
And I'm going to pick Cross Platform App (Xamarin). We also have a library template here
as well as a UI Test template to create behavioral-driven UI tests for your application
I'm going to call it App1 and I'm going to put it on the desktop and just click OK. That's going to give me a dialog here where I can choose
the type of app I want. I'm on Visual Studio for Windows. On Visual Studio for Mac,
the experience is going to look a little different. You'll have the same sort of options
but the dialogs you are driven through are going to look different and they're little more visual
I'm going to create a blank app, there's also a Master/Detail app that gets a bit more boilerplate code included as part of the project.
I personally don't like that, I prefer to just start out from scratch with the bare minimum that I can then build up.
Then I can pick my UI technology, Xamarin.Forms or native. This is going to decide the type of UI I want to build.
Either I'm going to construct the UI completely through the native UI toolchain
or I'm going to use a shared UI with Xamarin.Forms. Let's pick native so we can see what it looks like.
Then I'm going to pick my code-sharing strategy. I have two options: Shared Project and Portable Class Library.
Shared Project is source-code level sharing where all the files included in the
shared project are actually compiled into each of your applications.
Portable Class Libraries are a binary sharing technology where it actually generates a DLL.
that I add a reference to, and that DLL gets included as part of the runtime process
We're about to have a 3rd option which is .NET Standard. So, .NET Standard was just released and is now available for Visual Studio.
But it's not completely supported yet by Xamarin.Forms and it's also not listed here in the dialog. But you can create .NET Standard
assemblies - so you can create a .NET Standard library and then consume that
from all of your different applications as well. It's also not completely supported
right now by UWP and so there are some restrictions
there in terms of the types of things that can consume that .NET Standard library. All of that will be fixed very shortly and you'll be able
to simply use that. It will be the replacement for Portable Class Libraries. In fact if you look at the latest versions of Visual Studio
they are listing Portable Class Libraries as "Legacy" libraries, and that's because .NET Standard
is intended to replace that. I'm going to pick Portable Class Library. I tend to use this one
I don't want to get into a debate on whether to use shared projects or
portable class libraries because everybody has a different opinion about that
Often what I will do when I am building a Xamarin.Forms app is I'll use a Shared Project for all of my UI stuff
and then a portable class libraries for my actual business logic and things like that
and so I'll often actually combine the two approaches within a project and you can totally
do that - any combination is possible and you can do whatever you like.
You can see here that I'm going to create three different projects, one of which is a UWP app
and I need to choose the minimum version level that I want to use there
I just took the defaults. So let's quickly look at the different project types that we get here. The first thing I have in my solution is
a portable library project - this is because I picked the PCL option. This is going to generate a DLL. This particular one supports
a couple of different targets - it's .NET 4.5, ASP.NET Core 1,
Windows 8, Windows Phone 8, Windows Phone Silverlight, Android, iOS, iOS Classic and Xamarin.Mac.
This is what is done by default, you can change that if you'd like to pick different targets. Generally speaking,
PCLs have a fairly restrictive set of different profiles and so even if you start and unselecting things it won't
necessarily expand the API set. That's what .NET Standard is intended to address
But this is where I'm going to put all of my shared code. Things like my business logic, and my actual
logic that's going to run the app, behavioral type logic, perhaps my data models, and my web service code
So things things that are going to access web services. Maybe even my database code.
All of that can be thrown here into this portable class library or the shared project because it can all be shared
with my actual platform specific code. The platform-specific code is located in these other three projects.
We have one for Android, that has Android-specific stuff. We have one for iOS, that has iOS-specific stuff
and then we have one for UWP that has UWP specific stuff.
So let's start with Android. The first thing to notice is that
every one of these projects includes the portable class library as a reference
and so all the stuff we place in the PCL here is actually going to be available to us each one of these platform specific projects
The reason we have different platform specific projects is we're going to generate a different binary for each of those platforms
What runs on Android doesn't run on iOS and so we need a unique .EXE or .DLL or whatever the
project type needs to be to run on that platform. That's what these projects are intended to build
and create for you. In fact because we picked native UI, you'll actually find
that the structures that are contained within these projects are very much
influenced by the actual platform target itself. So in the case of Android here, I have a class that is a Main Activity.
It derives from a class Activity which is an Android type - in fact it's a Java class
and Xamarin is what is allowing that derivation to happen. Then we've got usage of APIs in our OnCreate override.
OnCreate is called when the application is launched and you can see here
we're getting the content view from our resources here
In Resources we have a folder called "Layout" and has an XML file in here called Main.axml that corresponds to this
That corresponds to Main layout here - that's going to construct a UI for us that has a button in it and a label.
You can see we are going to be retrieving that button here by it's ID and then we are going to wire up a Click handler to that button.
So that when we run this, we get a Button and as I click it, it's going to actually increment
the text of the button itself. I'm sorry, there's just a Button here - I think we're just changing the text of the button.
I also have an iOS project here, and in iOS I've got different files. I have a Main entry point that is a static void Main, so it's a little closer
to what you might be used to in the desktop world. This is calling UIApplication.Main which is an iOS API that launches our app.
It points to an app delegate. That's a different class here that you can see - AppDelegate; this derives from an iOS class
called UIApplicationDelegate. This is sort of our application-level kind of construct - it's what gets called initially, it's what creates
the initial UI. It has the actual window that we're interacting with when we draw things on the device surface and it's got some
different notifications here as the application goes through different states. So when we enter the background, or when we're activated
or terminated we get some overrides there that can get called to tell us what's happening with our app.
Now, in iOS everything typically gets created through a Storyboard and you can see here we have a Main.storyboard
and when you have a Mac host that is actually connected to your PC
then you can use a built-in designer in Visual Studio to drag and drop elements and about storyboard then you can use a built-in designer in Visual Studio to drag and drop elements into that storyboard
But I can construct my UI using the same sorts of services that I would use if I were building it with say - XCode.
Then of course, I have something called a View Controller. In iOS, everything that gets created is always done in the Model-View-
Controller pattern. Models are data objects, the controller is what actually drives the behavior of the app, and then the view
is what is defined in the Storyboard. So this View Controller corresponds to a page in my application and you can see its got
some overrides here for when we load, and if we've got some memory issues so we can do things
here in our DidReceiveMemoryWarning to maybe release some resources because we are getting low on memory.
And then this right here you can see is the same equivalent logic that we had in our Android application where we've got the button
that's defined in our UI. We are wiring up to an event called "TouchUpInside" with a delegate
handler that will increment some number of clicks and then set the title back on the button.
But the code doesn't look the same as the Android implementation because
the events that get raised by iOS and the methods that change things like the title of the button are going to be different
because we're using the native UI here, we have to use the native methods as well. But, the upside is, I can construct any
kind of UI that iOS allows here, and I can use every single control that is available to me.
even third party controls
that might be written in Objective-C or Swift, I could potentially incorporate into this application. Same for our Android app
I could use third-party things that were developed in Java and then utilize them from within my Xamarin app.
The world is open to me: I have every single API available, every single widget available.
Alright, so that's the advantage of this model. In the same way, I have a UWP app. Now, UWP is a little bit interesting because
UWP doesn't actually use Xamarin. In this case, it's just the regular UWP
application type that you would create if I
did a File > New > UWP app. So there's no Xamarin involved in this, in fact if you look at the references here,
you won't find any reference to any sort of Xamarin stuff. The only reference that we do have is to our portable class library
so again, we're going to share that behavior, share that business logic, share the database code, share the web service code, the source
things that are sharable, and then all the platform specific stuff where I'm dealing with
device-specific features, or I'm trying to talk to the file system, or I'm doing something
that's unique to that device, is going to be placed into these other projects
Alright - so that's our native UI. Let's try another one and let's build one for a Xamarin.Forms app.
and so I'm again going to go to cross platform we'll use App2 this time.
and I'm going to pick Xamarin.Forms and let's just pick shared project, just for fun;
And I'm going to go ahead and create App2. Now this is going to create a structure that's
pretty similar to what we just saw with the native UI. The difference is, we're going to find some
some additional classes that are actually going to be located in our shared code, and specifically
we're going to find some UI constructs because it was Xamarin.Forms I'm going to be able to
define my UI in a standardized fashion, that's shared across all of those platform specific projects.
You can see here that we're going to get a new Universal Windows project, so we'll just pick again the defaults
and then we'll see what got generated here. So let me kind of collapse some of these up.
Notice that our shared project here has a different icon here indicating that it's shared.
It has two files in it - App.xaml and MainPage.xaml.
So we actually describe our UI in XAML, we'll see a little bit more about that in a second.
You can see here that we're creating a ContentPage. A Page just represents a single screen
typically defined by ContentPage. It's a specific type of page that has content. ContentPage can have a single piece of content so typically
we'll have a panel in here, and that panel will have other children. In this case, we just have a Label - "Welcome to Xamarin Forms!"
It also has an App class - the app class is a singleton, kind of like other UI technologies that you are probably used to.
It derives from Application and has some overrides here, similar to what we saw with iOS where I have
Start, Sleep and Resume telling when the user is actually going back and forth between my app and other apps.
And then I've got my three platform-specific projects again. Notice again I now have my App2 included
as part of this. It's a Shared Project so again, it has a slightly different icon.
But it's being included as a reference here. I have some other things in here as well so notice
that I have Xamarin.Forms.Core, Xamarin.Forms.Platform,
Xamarin.Forms.Platform.Android, and then Xamarin.Forms.Xaml
These are the Xamarin.Forms assemblies and so these are added because we used a Xamarin.Forms project.
and then finally I have again Mono.Android which is the runtime for Xamarin.Android. On the iOS side, I have
the same kinds of references, I have App2, Xamarin.Forms.Core, Platform, Platform.iOS instead of Android
and then Xamarin.Forms.Xaml, and then i have reference to Xamarin.iOS which is the runtime for an iOS app.
Notice that we have an AppDelegate here but we do not have a Storyboard in the iOS app because
the UI is not going to be done through a storyboard, it's going to be done through this MainPage.xaml.
or whatever set of XAML pages I might have in here.
In the same way, while I do have a MainActivity in Android, notice that the MainActivity doesn't actually inflate any sort of UI.
I don't actually have any UI in my layout here. We do have a TabBar and a Toolbar,
that potentially can used, those are just resources that are here; but it doesn't actually have a main.axml like we saw
in the native UI. Instead, we are going to initialize Xamarin.Forms and then load our application up from the Xamarin.Forms side.
So, it's Xamarin.Forms that's going to define that UI but I still have a platform-specific project to put platform-specific stuff in.
Again, I can still use all the features of Android, or all the features of iOS, or all the features of UWP.
So here's my UWP app here. It's just that instead of having the UI defined in each of these projects that's independent and separate,
I'm typically going to define as a shared resource, where this one label will inflate to a bunch of different types on the runtime side.
This is sort of the basics of
the Xamarin application solution and the structure that's contained behind it. So let's go back and lets look it sort of some differences
that you might see as you kind of build Xamarin apps vs. your desktop apps.
As I mentioned earlier, I'm going to restrict this comparison to WPF and beyond,
and specifically look at Xamarin.Forms since it's the closest.
If you decide your app UI is better suited to a native UI approach, that's great – you'll just need to reset your expectations on reusing any
UI type code and provide some layer which connects the native UI controls to your behavior and logic.
Let's start with the big picture. Xamarin.Forms actually took a lot of design hints from WPF and Silverlight. So much of the features and
capabilities you are used to in that world are also available in Xamarin.Forms.
Some of the features are almost identical. For example:
Data Binding, Triggers, Styles, Behaviors and XAML all pretty much work the way you'd expect them to.
Some features have some API surface differences. For example, the Application singleton class
has different methods and properties available on it which are mobile oriented.
And then some capabilities are exposed in a different fashion today. Animations are a good example of that – there is no Storyboard in
Xamarin.Forms. Instead, we build and start animations in code instead of XAML.
So, let's look at some of the key differences which tend to bite new developers coming from other XAML platforms.
So, Xamarin.Forms supports using XAML to describe a UI layout. Syntactically it is identical – elements create objects and attributes set
properties and wire up events. In fact, the XAML parser with Xamarin.Forms is even better than what we had before because it fully
conforms to the XAML specification and supports all the cool additions that WPF never got.
The difference is in the UI controls you create and the properties you work with.
Here we have two UI screens created with UWP on the left, and Xamarin.Forms on the right. Notice that we are creating the same
basic UI, and both representations here are XAML. The difference lies in the controls used to describe the UI.
On UWP we have a TextBox and a PasswordBox;
on Xamarin.Forms, the Entry control serves both purposes based on a property value.
On UWP, we have a more relaxed content model where buttons have content properties
and can have non-textual values.
On Xamarin.Forms, we can only have text in our buttons – so we expose a Text property.
Notice as well that our color properties have different names.
Ultimately, when designing UIs with either the native UI or Xamarin.Forms approach, knowing the control set and properties is the key bit of
new knowledge you will need to learn. So, we'll see the control set again in a second.
Another key technology present in Xamarin.Forms is the data binding engine. This allows you to loosely couple a piece of data
exposed through a public property on a .NET object to a visual property on a UI control.
The rules are identical to other Microsoft implementations
the source object can be anything as long as it's public, and the target must be a specific property type – in this case, a
BindableProperty. In other systems, we call this a DependencyProperty, but the purpose is identical.
It is a specific class which works with the binding engine to do it's magic.
Bindings can be OneWay or TwoWay, and each BindableProperty decides the default so it's a good idea to
be explicit in your binding when you set them up if you aren't sure what the default is.
Just like other data binding engines, you can create and apply bindings in code or in XAML. In fact, these two lines of code
here could be used in WPF, UWP or in Xamarin.Forms.
There are some differences though – as you saw, we use BindableObject and BindableProperty instead of DependencyObject
and DependencyProperty. Those original names given to the WPF classes were used because they did a lot more than just provide
binding support. However, much of that additional feature set was lost as they were reimplemented in Silverlight, WinRT and UWP.
So, Xamarin.Forms chose to name them something a little more closer to what they actually do. The same thing is true of the
DataContext property. In WPF and UWP, we use this property to assign a default binding source
for all bindings applied to that element or a descendent of that element.
We have exactly the same feature in Xamarin.Forms – but the property name is BindingContext.
Here you can see the WPF code assigning a view model to the DataContext, and the same line of code
in Xamarin.Forms – assigning the view model to the BindingContext property.
Another difference is in the binding markup extension. In WPF and UWP, we have an
ElementName property which allows us to bind to other visual elements in the same XAML tree.
That support isn't available in Xamarin.Forms, instead it includes the x:Reference feature
from the 2009 XAML specification and allows you to just use that with the Source property.
This is a more standard XAML way to identify another element by name
and so it was the approach the Xamarin.Forms team decided to take.
There are several other differences that we don't have time to cover today. For example, there is no support for compile-time bindings
with x:Bind, and other less-used features from WPF
such as binding validations, multi-binding and binding groups are not implemented in Xamarin.Forms
Constructing User Interfaces is a big part of building an app, no matter what technology you use.
Xamarin.Forms adopts the same basic layout management that you will find in WPF and UWP. Layout containers, or panels
are used to organize children based on some defined set of rules.
The layout system uses a two-pass "Measure" and "Arrange" algorithm to position elements
and you can use pre-supplied containers for layout, or if necessary, build your own layout containers to apply custom logic.
Since the layout containers are so prevalent in our UI, it's helpful to compare them.
Here are the built-in panels from WPF and UWP as compared to Xamarin.Forms.
As you can see, there is a lot of overlap between the styles of panels. In some cases, the panel is only available on one platform
for example, DockPanel and UniformGrid only exists in WPF
and RelativePanel is only available in UWP, although we have a similar container in Xamarin.Forms.
In many cases, the panels work the same way. StackPanel and StackLayout, Grid and Canvas all work the same
across the platforms – although there are some subtle differences when you get into the details, particularly when you are not explicit
about your layout properties as the default behaviors tend to be different.
The important thing here is that the layout behavior is very similar so if you've used a
StackPanel on UWP, then StackLayout in Xamarin.Forms will feel very natural to you.
Finally, keep in mind
if you need a specific layout design, you can always build a custom panel.
There is a WrapPanel example in the Xamarin.Forms documentation
which you can look at for guidance,
and Xamarin.Forms is completely open source so you can always go look at one of the built-in panels to see how they work.
The area where things do quickly tend to get tricky is in the layout properties themselves. Each panel has unique properties
it uses to control layout characteristics, and each control exposes properties to help position itself within the parent container.
In some cases, it's just a name difference, in others, there are differences in behavior depending on what the parent container
happens to be. But this screen is a good mapping of the properties so you can play with them to get exactly the layout you want.
Xamarin.Forms defines it's own UI elements that we use to construct our user application
and just like other UI frameworks, Xamarin.Forms has a visual lifecycle for the application.
Xamarin.Forms defines each screen as a Page. So, when you display a screen of data to a user,
you are really defining a Page object with visual elements that the user can interact with.
when the application is launched it identifies the starting page referred to as the "Main" page
It creates the main page object and then calls a series of virtual methods and events to notify the app that things are happening.
OnStart is called when the page is first loaded. Appearing is raised just before the page is displayed. If the user switches away
to another app, the OnSleep override is called, and when that user switches back to our app, OnResume is called.
Finally, just before the page is destroyed it raises the Disappearing event.
Also, keep in mind that these interception points shown here are part of Xamarin.Forms and therefore common to all supported
platforms. If you need more detail you can also override platform-specific
events and virtual methods that are in the platform-specific projects.
On each of your ContentPages, you'll define visual elements, or controls that the user interacts with.
The Controls implement the core functionality of your UI.
All the most common controls are available directly from Xamarin.Forms as you can see. There's also an active third-party industry that
provides specialized controls and you can create custom controls if you need to.
The interesting thing about Xamarin.Forms controls is that most of them are just thin wrappers around the platform-specific controls.
Unlike other UI abstractions you might have worked with, Xamarin.Forms always generates a fully native UI – just like the
one you might have created if you were using the native UI controls directly
Here's an example. If we want to display a piece of static text in our UI, we will create and place a Label element into our Page.
In Xamarin.Forms, that Label object is just a model which at runtime is processed by a renderer that is platform specific.
iOS, Android, and UWP all have unique renderers which take the Label definition
and then create a real text object that is unique and specific to the platform it is rendering on.
So for iOS, we get a UILabel added to our view, on Android, we get a TextView, and on UWP, we get a TextBlock.
The key thing to understand here is that Xamarin.Forms doesn't do the rendering on it's own – the visual elements that will be created
by your UI definition are the native, platform-specific controls that every app running on that device uses.
So even though you are using Xamarin.Forms to define a shared UI, the actual UI itself
will look and behave like it should because it's fully native
The downside to Xamarin.Forms is that it only includes the most common controls which all the platforms support.
So, unique controls that are only present on a subset of the supported platforms are generally not available to your Xamarin.Forms application
You can override this limitation very easily however. Xamarin.Forms allows you to embed native controls directly in your UI. Here you can
see we are utilizing an iOS UISegmentedControl and putting it into a Xamarin.Forms StackLayout.
The key thing to note here is the #ifdef statement which restricts this code to iOS
This approach only works when you are compiling this code directly into each platform specific project.
That means to use this feature you will typically want to be using the Shared Project approach.
This will allow you to use the types that are specific to the platform.
I'm showing C# code here to make it clear what's happening, but you can also use
conditional tags in XAML to do the same thing. As with the code shown here,
you would have to have that XAML in a shared project which is compiled directly into each of the platform-specific project.
Now that we've seen some of the API differences and features of Xamarin.Forms, let's look
at a couple of examples of porting desktop style applications to Xamarin.
Ok, so back in Visual Studio, let's close this solution that we created here and I'm going to open up a couple of other solutions.
I've got some pre-built things that I actually already created and that I've worked with and I've got a Github repo that you'll see at the end.
and there's two different projects here that I want to show you. The first one is a
Windows.Forms project. So this was a desktop app that I found on Github and I asked the author if I could use his project as an example
and what he does here is, let me just run it so you can see it; it's a Craigslist scraper application.
and so you can pick a city that you happen to live in, I'm in Dallas, and you can search for things like
"teslas" and it will actually go through and hit a CraigsList
endpoint and then scrape all the data off of it and display things, and if you double-click on one,
just double click, and will open up a web browser
and then actually display that particular entry from CraigsList - so it will just open it up for me from the Dallas Craigslist.
Now, in the Github notes you'll find the actual link to the original repo. The very first thing
I did as I decided to port this application, is I went ahead and updated it
for the latest revision of .NET
and I went ahead and upgraded it to use like async/await and things like that
and I made sure it all continued to run properly here in this project.
Then I went ahead and copied that project and I created a new version of it.
What I did as a starting point, once I'd upgraded it to the latest version of .NET, is I went ahead and took all the portable bits
of it, things that I knew I could share, and I moved it into a portable class library.
And so just as an example I moved to the definition for a single item into a portable class library.
You can see here is the item. It has a link and a price, and a date, location and title
and I also moved the logic that was going to do the screen scraping, or at least the XML parsing and such that came from the API
and I moved that into a static class and so here you can see is a search method with the
city and a search term; all this code was originally part of
the actual Windows Forms app, and I then updated the Windows Forms app to
ensure that it continued to run; so you can see here it is right here and I still have my same form
and so the form is still there and the logic for the form is all still present; the difference is that instead of having all the logic bound in
the form itself, I went ahead and used my new version of the API and I tested it and made
sure all continued to work. So you can see here I can go back to Dallas and I can search for "cars"
and again I get my list, and I can still double-click on a car and it opens up a web browser and you can see that I get my car there.
Then, I went ahead and added a new project into this, and I added a Xamarin.Forms app and that created for me these
projects right here. So you can see I have a portable class library, I have my Android, my iOS and my UWP.
In my portable class library, I defined a version of this page to represent this app in a mobile form; so I had to redefine the UI
because clearly I can't share Windows Forms definitions and you can see here that I went ahead and
created a search bar and a picker to list the cities
and then I have a ListView here, that when I tap an item, it does something. Then I created a data template
for the ListView to actually represents the car or rather the Craigslist entry itself
and I started with just a regular text cell, so just a regular textual representation binding to the same thing that the
Forms app was using; so if we look at the Forms app just as an example here you can see
it's data source is coming from those search terms and so it comes back with a list of items
and then its using DisplayMember of "Value" which is just a ToString representation
I did the same thing here and just bound to that same Value property
and verified that it worked and then kind of extended it to show things in a little bit different fashion so let's actually run one of these
Let's go ahead and run the Android version so I'm going to set this as my startup.
and then go ahead and run this in the Android emulator.
That's going to take a second because it has to build this application and then it has to launch the emulator
but it'll bring the emulator up and then we can actually see our application run
so now that my emulator is up, I can actually pick my city and so again, let's just pick Dallas.
And I can type in my search term here - let's do our "tesla" again
and then notice that it runs and I'm going to get my actual results here - and this is where it's displaying in my data template; so just like
before, if I tap on one, I'm actually launching the web browser right here on the device and I'm actually able to see it right here
this particular entry from Craigslist, and I can go back and go and pick a different one
and see what that one looks like. This is the same exact app, using all the same code behaviorally that the Windows Forms
one did with a different UI here. Now, I can do the same thing for iOS
and so if we switch over to the iOS app and set this as our startup; you have to have a Mac host for this
but you can see up here, I've got my Xamarin Mac Agent and it's connected to my MacBook Pro in the corner, and once it's there I can
see all the emulators and simulators as well as any devices that I have connected and I can tap the button and it will build,
go ahead and create the package on the Mac, and then run it on the Mac, and because I'm running the enterprise edition of Visual Studio,
it can actually remote the simulator from the Mac back here to my
Windows machine so I can actually see and interact with it right here in Windows.
You're going to see that I get essentially the same UI. I'm going to have a search bar and a picker, and then a ListView below it.
So, we're sharing that UI definition - that's the benefit of Xamarin.Forms. But notice that
it doesn't look the same because I'm using an iOS search bar here.
So let's pick Dallas again.
and then let's go ahead and type in our "Tesla"
and then you can see that I get all my Tesla information here, and I can pick one,
tap on it, and it opens up the web browser, just like we saw on Android.
Although, interestingly enough, it's not displaying the .. oh there it goes
so here's one for 65,000
and go back
and let's try this last one, 52000
ah, that one's pretty - a nice red one.
So you can see that it actually runs right here inside the simulator
The last application style we have here is the UWP app and this one is actually quite interesting because
this Xamarin port allowed me to actually create a more modern version of the desktop app,
so notice I can run this right here on my local machine
and notice it comes up here
I have my "Search Craigslist"
and again I have my drop-down here, I can pick my city, I can type in
whatever I'm searching for - and then it will come back with my data. Now, I changed this, so notice that on UWP, we don't put
a border around it like we did on iOS and Android. So you do have the ability to style and theme the app based upon
the operating system it happens to be running on. So let's pick Lincoln Town Car
and again it's just going to open up a browser and display the Lincoln Town car
But this is cool because I'm actually able to create a desktop representation of this with UWP, and reuse all the code
that we'd already build for the the Windows Forms app; so it gives me an immediate upgrade path
to the latest sort of edition of the desktop APIs
While allowing me to share all that code, and I've got a shared definition here for the UI itself.
So, that's a Windows Forms app. Let's try another app. I've got one other example here that I want to show you.
and I'm going to backup here and let's go into vacation spots. Again, I'm going to open up the original.
This was a WPF app, and this app here uses MVVM to be able to structure things. Let me just run it to show you what it does.
The idea was to kind of demonstrate data binding capabilities and things like that, it was a vacation planner application. You can see here
that I can select different places in the world that I'd like to go to: Dominican Republic,
Maui, Cancun, I can scroll down and see there's
places in Thailand and Australia; so maybe I'd like to go to Australia. It gives me some
information about it that I might want to know about this particular vacation. You can see it's all colors and images, kind of the
2009 look of a desktop app with WPF where you kind of went wild. So, again, just like before, the very first thing that I did with this
was, I started to break it out into a common set of code that can be shared and then the visual representation which was WPF.
So I created a VacationSpots.Common, this has all of my view models, and notice it has all of my
data and in fact, it even has the base view model implementation here
as well as the DelegateCommand implementation here that we're sharing with the WPF application.
So all of this got moved out of the WPF app and moved into a common, portable assembly here.
Then, I created a Xamarin.Forms app which gave me
the portable UI definition, so again, I have a MainPage.xaml, I have my App.xaml, I have an Android implementation, iOS and even UWP.
Now, the cool thing about this is, I decided to change the UI. That UI that we had for WPF,
Oh and by the way, I still have the WPF app, again the first thing that I did
was to ensure that the WPF app continued to run the way it was supposed to
I separated out all that code, and then made sure that the WPF app
continued to look correct when it ran here, so you can see that
I still have all my data here, and it's all still running the way I expect it to.
But then I started out with my mobile apps - let me just start with the UWP app here, so I'm going to set it as my startup. I decided that
the UI that we created on the desktop side, wasn't really appropriate for a mobile app.
A list with images - we could totally do that, we've got a Master/Detail view..
we could have a ListView on one side, and then as you select things in the ListView, have your details view change with images and
details about it, but I thought that's really not mobile centric. That's not what a mobile app
normally would look like and so, instead what I used was called a carousel view
a carousel view lets me sort of swipe between different entries
and so my app is up now, and you can see here I got my Dominican Republic
and I can actually click the little buttons here to swipe between the images, but
they are nice and big and pretty. My actual details here is just in a box that
goes up and down based upon me tapping this little icon here - and so as I tap ..
this area, I can actually get it to go up and down. Notice that it by default
just displays the location of where this particular image is coming from
and the same sort of UI is available on my other two platforms. So if we set our Android project as our startup and we run this..
Here we can see our app is running on Android and instead of little arrows, I can just simply
take my mouse and slide, but my up and down still works
And actually it's anywhere in here you can tap and it will go up and down not just the arrow - obviously touch you have to
expand your range of what you can actually tap in order to make it go up and down. So, this whole area is actually the tappable
surface, but the arrow sort of indicates that we can slide this up by touching here.
so let's look at some commonalities here. So again if I go back to my WPF app
and I open up the XAML file here, you can see that
it uses a DockPanel, has a border around
a TextBlock for the title, then it has a status bar at the bottom.
and then here you can see here's our actual list of vacations inside of a list box with a group style as well as a data template
to display the actual image along with all the text blocks. It just got a lot of XAML and it's all based on WPF so you can see Dock Panels
and Stack Panels and TextBlocks and things like that. Then it's got the actual details view which is just a UserControl.
On our mobile side, if I go look at the MainPage here
you're going to see it looks very similar, I have a Grid, I have some resources in the Grid
with a Style for my Label. Notice that in our Grid resources
if you're familiar with WPF, this is very similar - I can put all my Styles inside here. The only difference is I have to declare the
Resource Dictionary; and so unlike WPF where you just start adding styles and there is an implicit
resource dictionary that has been created for you; you have to actually declare the resource dictionary here as part of
of the resources. And then I've got my row definitions with a star-sized height and an auto-sized height, that's all exactly the same
as other XAML frameworks. Then I'm defining my CarouselView. So this is a unique control
to Xamarin.Forms and it uses data binding, so notice it has an ItemsSource that's bound to that same AllVacations that
we use here, and so on the ListBox, notice we're binding to AllVacations right there.
we're binding to to the same AllVacations here and our item is bound to SelectedVacation so the actual Main ViewModel that's driving all
this is identical between these two projects. We have a MainViewModel here that's actually got our list of AllVacations
and our SelectedVacation and it raises property change notifications in order to say when
things are changing. That's all shared code between the WPF
and all of our mobile projects. Then I define a data template that has our image in it
and then I have the frame that moves up and down so this is the
animated frame. Now, that animation, unfortunately we don't have any way to actually describe that in XAML today
at least not for Xamarin.Forms and so the way that's actually setup here is in the MainPage.xaml.cs when you tap on that
frame, I'm running a little bit code in order to actually run those animations. And so you see we have some unique APIs here to animate
and rotate and fade those elements; and so those are animation APIs that are built into
Xamarin.Forms to be able to do the work that I'm trying to do here, and it's all driven off
this one single little method that's in my code behind. So this is unique to Xamarin.Forms
but the actual data storage, and the representation of that data, where it's being loaded from
and all that code that's part of that, is all actually contained in our common
assembly and then it's shared across all of our actual platform-specific
projects, so our UWP, our iOS and Android as well as, of course the WPF app.
So let's switch back to the slides.
For this final part of the session, I want to impart some practical
tips on engaging the mobile development experience.
These are things I learned the hard way which I hope will be lessons that you can take with you.
First, embrace minimalism. Mobile apps aren't desktop apps. On the desktop we have tons of resources – and so most desktop
apps do lots of things for you. When shifting to the mobile arena,
consider what the core functionality of the app should be and focus on that.
Each screen in the app should be devoted to a single thing with navigation
provided to get to other core features you need. Here's an example:
On the desktop, my mail application has lots of screen real estate, so we show
folders, messages and a full message thread all in one window. We also have a toolbar
with common functions, and a search bar to find and filter my messages
When we translate that experience to mobile, we define the core tasks:
reading messages. So we reduce the window to a search bar and the messages
contained in a specific folder. Context menus are still provided, but utilize swipe gestures, or long press gestures to activate.
Notice that we provide a preview of the message, but require that you tap on the message to actually
view the entire contents. At the bottom we provide the most common tasks – New Message and a folder view to switch folders.
We can also utilize orientation to change our features. For example, if I rotate the device horizontally,
I can then display the message list and the full message thread for the selected message.
Notice I also then have room to expand the message options – so I can do quick actions right here on the same screen.
This sort of feature focus reduction is very common in the mobile world, I encourage you to look at other apps
which have desktop parallels – particularly from Google, Apple, and Microsoft to see how they transition to mobile in this regard.
The second piece of advice is to embrace the platform. Each mobile platform has a unique way of doing things.
Users expect their apps to behave in consistent ways and so when you deviate from the norm, you should have a very good reason.
And then, sleep on it before actually doing it!Here's an example. The navigation paradigms for each platform are different.
On Android and UWP, it's common to use hamburger menus, located at the top.
On iOS, it's far more common to use tabs.
Always prefer the standard navigation system used by each platform.
Remember that UWP and Android have back buttons on the device and iOS supports a swipe
off the edge gesture to go back. The app shown here is a Xamarin.Forms application –
but notice that it adopts the proper design based on the platform. This is ideal because it's what users expect.
In fact, each vendor goes to great lengths to document the expected user experience.
Android publishes the Material Design specification with it's flat, shadowed designs with floating buttons.
Apple has the Human Interface Guidelines which provides details for every one of their platforms from macOS to AppleTV.
And Microsoft has the Fluent design language, which is an extension of their Metro Design language created for Windows 8.
Read these specifications, examine their built-in apps, these are the standards
you want to employ so your app looks and feels natural on the platform.
Number three: embrace touch. This might seem like a silly thing to say, but think hard about how people interact with your UI.
Mobile devices are touch based and fingers are much bigger and less precise than a mouse.
Make sure your interactive visual elements are large and not spaced too closely together
Think about how users hold the device while they interact with your application. Can they get to all of your features easily one-handed?
This is important because a 2013 Steven Hoober study documented how people hold their devices and almost half of them tend to
use it one handed. If your app requires daddy-long-leg fingers to reach core features then you are going to have a usability problem.
Mobile devices have some unique challenges which you just don't find in the desktop world. Embrace those differences!
For example, it's common to have your network connection just disappear while you are trying to utilize it. Having robust algorithms to retry
data operations and offline caches of critical data is mandatory in the mobile world.
Your app also doesn't have the CPU or memory resources your desktop apps are used to. You need to consider all the low end
devices people might run your app on and compensate by only keeping what you need in memory and offloading CPU intensive
algorithms to external web services where possible.
Users will use your application in unexpected ways. If it doesn't respond immediately, they might tap or swipe things again and again so
disabling visual elements and providing them some feedback that your app is doing something is important.
And your app has to be robust. Unlike the desktop where apps are opened and closed all the time, or where an application crash is a
minor annoyance and the user just restarts the app, mobile apps are expected to be rock solid. They also don't have complete freedom.
Typically the only time they are given the CPU is when they are in the foreground. Switching away from your mobile app will often suspend
the application with a few special exceptions.
Knowing these rules and exceptions is important to building a robust, high quality application.
That brings me to my final piece of advice. Always test on real devices.
Simulators are wonderful – they are quick and often easy to test with, but they don't exhibit the same performance or complete behavior of a
real device. There are a lot of touch gestures you cannot completely replicate on simulated devices, hardware buttons and on screen
keyboards might behave differently, and most devices support physical interactions to do things such as take screenshots.
Make sure to test your app on the types of devices you expect your users to have.
As developers, we often have high-end hardware that our apps run great on. Then it gets installed onto a real users device and the
performance metrics are quite different. So, test on all the supported variations you expect your app to run on.
To help with that, consider trying out Visual Studio Mobile Center.
Mobile Center covers the entire application DevOps lifecycle from end-to-end, with deep functionality in each area.
One of those areas is Test Cloud which is an automated testing platform I mentioned earlier.
Recall that it allows you to run your application on real devices with a testing script you build to run it through it's paces.
Test Cloud will execute the script on the devices you select and generate a full report on
what worked, and more importantly, what didn't. That way you don't have to invest in every possible variation of device – you can
use our system to do that for you.
Mobile Center is currently in preview – you can sign up today at mobile.azure.com and try it out for yourself.
Well, we've reached the end of our time this morning.
I hope I've given you some ideas on how to get started going from the desktop to the mobile world with Xamarin.
I want to remind you again about our excellent training at Xamarin University.
We've got all kinds of content – a lot of it is free, but we also have a subscription service where you can get trained by Xamarin experts
who have been building apps for years. We've got over 80 classes on a variety of topics to make sure you get the information you need.
and subscriptions start at just over $83/month
and you can use the same subscription you use for Azure services or your Visual Studio MSDN subscription.
Finally, here are some additional resources and links you might be interested in.
We will be posting a recording of this webinar and the slides and demos I did in this session are in the GitHub repository listed here.
Make sure to check out the slides in particular, there are some things I didn't have time to get to today.
Alright – I hope this has been helpful to everybody, thank you so much for attending this webinar with me today.
We're going to stick around and make sure everyone gets their questions answered, so I'll end here, but feel free to engage with our
online experts in the chat window. Thanks everyone – have a great day!
For more infomation >> The EASIEST WAY to PROVE to YOURSELF that YOU CREATE YOUR REALITY! (Law of Attraction) - Duration: 8:34. 
For more infomation >> 5 Tips to keep the flame on in your relationship - Duration: 3:46. 
Không có nhận xét nào:
Đăng nhận xét