>> Welcome to The Xamarin Show.
You're not James?
>> I'm not James.
>> I'm not James either, so what's happening?
>> Well, my understanding is you came all the way from
Switzerland to do a show with James.
>> Yeah. He was all booked,
and James is like,
"I'm not going to be here, I'm in island."
So, James is in an island right now.
He's, I don't know,
visiting or looking for leprechaun or something.
>> Having a good time apparently without us.
>> Probably. So, basically James said,
"Well, since you're there and I'm not,
why don't you do The Xamarin Show.
So, my name is Laurent Bugnion,
I'm a Cloud Developer Advocate,
I work for Microsoft. Jeremy.
>> My name is Jeremy Likness.
I am also a Cloud Developer Advocate,
and I also work for Microsoft.
>> Perfect. So, you're on the .NET Team.
So, basically what we have
is Cloud developer advocates
that we all have some expertise.
So, my expertise is in Xamarin and .NET.
I do a lot of cross platform.
You are a little bit less, right?
>> A little bit less. I haven't really worked
with Xamarin Forms at all,
but I do everything done at base and I always tell
people back in the day I was
a huge Silverlight developer, right?
>> This is when we raise our hands.
So, yes, Silverlight was awesome.
Definitely, they paved the way for a lot of things.
Now, we have really interesting thing
in Web Assembly, Blaze, or etc.
It's not the topic of this show,
we'll come back to that another time.
>> Sure.
>> But, that thing really is the thing I thought about.
Initially my idea was to talk about .NET Standard,
because .NET Standard's super exciting,
it's three cross platform and really way more than
before because now we can even go on
Linux with this cross platform.
With .NET Core applications, for example,
we can go on Mac OS,
we can go on Windows on all platforms.
Super exciting and it so happens that
Xamarin Forms use these .NET Standard.
>> Yeah. I've always wondered, how does that work?
Because Xamarin Forms is a UI thing.
>> Yeah, that's correct.
>> It's using .NET Standard,
that goes Linux, Mac,
what you said so.
>> Absolutely. Correct. So, of course,
Xamarin Forms works on iOS,
Android and Windows UWP,
so no Linux here.
>> Okay.
>> But, I want to show you how it works.
So, here I have Visual Studio 17 on my machine,
and I'm going to create a new project.
So, the idea here is that you go under
cross platform, and you select
the mobile application for Xamarin Forms.
I'm just going to use the default names,
we keep it simple so that we see something.
I'm going to choose the Master Detail.
So, basically this is a template which
already has a little bit of data inside,
so that you can get started.
If you want to get started from scratch,
you just choose a blank application with nothing at all.
>> That's the clean slate and you have
to build it up from scratch?
>> Absolutely. Here at the bottom, we have the platform.
So, we can choose at the moment, Android, iOS,
and Windows UWP, so
Windows 10 Universal Windows Platform.
So, the really interesting thing for us .NET
people is that you can choose a code sharing strategy.
So, we have a shared project.
We'll maybe talk about that a little bit more,
but what is really interesting for us
is this .NET Standard option.
So, let's create the project.
It's going to take a moment to
update older and you get packages.
I mean this is a standard thing going on,
and what you will see created here
is four projects. Why four?
Well, we have one project per platform.
So, we select these three platforms, we have UWP,
Android, iOS, and those are basically
what we call the heads project.
They are what you select when you want to say,
select it as a starter project, for example, okay?
So, that's what you're going to
create to deploy on your device.
In the fourth project,
which is the one which is really interesting for us,
is this project which is on top here,
and this is the shared project,
where you have everything you need,
and mostly what you try to do is that you
try to work only in this shared project,
because everything you do there is going to be shared.
>> So, less code duplication,
and I'm looking at the project and this
is very familiar to me.
If you've done WPA for Silverlight,
I see our app, Zamel,
I see three models, I see views.
>> So, this application has
already a little bit of data, like I mentioned.
So, this is following the model view,
view model patterns, old patterns
that we know and love, I hope.
So, basically what the Xamarin Forms
supports is data binding,
we have two-way data binding in the books.
So, that's very familiar,
like you say to people who did CVLI,
WPFV4, it's really well-known.
So, here we have those Android, iOS,
and UWP heads projects,
and inside the shared project,
which is really where we want to work,
we have a few interesting things.
So, for example here, if I expand,
let's say, the main page of Zamel.
As you can see, this is Zamel,
so this is very familiar here.
In that particular case,
we don't have really a binding,
but if I go to the item detail page, for example,
here we can see that we have some data binding,
I can make that a little bit bigger.
So, this is two-way data binding,
that case it's a label,
so obviously it's a one way binding,
but basically we are very familiar with that.
So, the view models are here in this folder.
So, again, well-known.
>> So, I was going ask
the Zamel here is in that main project,
so you're actually sharing Zamel
across Android, iOS and UWP?
>> Correct. So, the way that it works is on
the controls that you set in
the Zamel are going to be rendered.
Okay? So, we have
these objects that we call default renderers,
and then you can also customize those.
So, you can create your own renderers.
So, basically what it says that a label here in
Xamarin Forms is going to be rendered to
a text block in Windows UWP,
because on Windows we use text block, choose show text.
Then on the other hand, if you go on the Android,
then it's going to use an
Android control called the text view.
Now, you can change that.
So, if you are not satisfied
with that, you can change it,
and then you can customize and
use any control that you want instead of that.
Or you can say, no,
every time I'm on Android,
I want the font to be read, etc.
>> That's very cool.
>> Yeah. So, basically this is
an abstraction if you want of the UI,
and that's what Xamarin Forms does.
>> Okay.
>> Cool. So, now we have these.
Until now, we can actually run the applications.
So, if I go and select, for example,
the UWP as a starter project here,
and then we need to run this with "Control + F5".
So, it's simply going to build the application.
It's going to run the application here and then we'll
see that we already have a little bit of data.
Then, we can do the same on Android as well,
so I'm going while it's starting to just
navigate to the application.
Select it. All right.
And then after that, I'll share my screen
quickly, so that you can see.
So here, we have the UWP application starting.
First load, it's slow.
>> You know the trick, right?
So, you move your mouse clockwise,
and that speeds up the loading.
>> Is that so?
>> Yeah. I need to try that out, yeah.
>> Cool. So, here we have the implementation.
Okay. We see the items.
We can navigate.
There is a back navigation,
which is again, right,
a UWP feature, but it is used by Xamarin forms on UWP.
You can add a new item if you want, et cetera, et cetera.
So that's working. Now, if we want to show on Android,
what I'm going to do is quickly
start this application called
Vysor which allows me to synchronize my Android phone.
Now, you could run it in an emulator, if you prefer.
Right? We support of course,
all the Android emulators.
We also have iOS, and so here,
I'm not going to run iOS because I didn't take
my Mac with me from Europe all the way.
But basically, you can build on a Mac.
You know that in Xamarin you need a Mac to build for iOS.
But after that, you can run it on
an iOS device or also in the simulator.
So here, if I show my phone screen, here we go,
and then you see that the application is already
running on the phone, and same thing.
Very similar, but it is
using Android controls, native Android controls.
So basically, we are really using native UI,
which is good because it is faster,
and it is also using
user-experience paradigms that the user knows.
For example, it is integrated with,
if you have a text field
for input support spellcheck, et cetera, Out of the Box.
>> So, does it automatically do things like taking
menus and collapsing them into hamburgers and-
>> So, you would have to add that,
but under the cover, it's using- So,
if you want to have a drawer for navigation
and these kind of things, you can of course.
Those are also controls which exist.
Under the cover, it is using
the native controls to do that.
>> Very cool.
>> Yeah. Cool, so
seeing the basics of
the Xamarin forms application, I would say.
But, what is really the
interesting for us .NET people is this,
Xamarin forms is using .NET Standard under the cover.
So, if I go and show the properties of this project,
we see that this is a .NET Standard 2.0, right.
So now, those versions can be a little bit confusing.
So, do you want to maybe tell us a little
bit more about what is a .NET
Standard 2.0 versus 1.0 versus what is .NET Core?
This is just a little bit confusing for the users.
>> Right. I run into this all the time.
So basically, we have a little bit of history
in .NET development of how
we share projects and share code.
In the old days, we'd do it manually.
Unfortunately, we would literally
copy a link to a file and use
that same file which was pretty
inefficient and a maintenance nightmare.
Then, we got something called
Portable Class Library or PCL.
PCL was great because it allowed
us to target multiple frameworks,
but the way PCL worked was lowest common denominator.
So in other words,
if you had 15 different frameworks you were targeting,
it would find the subset of
APIs that all those frameworks used.
The problem with PCL
was that the more frameworks you picked,
you could pick old versions or new versions,
the more you pick, the less surface area you had,
the fewer APIs you could call.
So, when .NET Standard came out and did was,
it created a target for implementation.
It raised the bar .NET Standard 1.0 said you must
implement these interfaces to
be.NET Standard 1.0-compliant.
>> All right. I think .NET Standard 1.0 was really aimed
principally at Websense because they
wanted to implement ASP.NET Core.
That was really the idea.
And why do we want ASP.NET Core?
It's because on Azure,
we support Linux web servers, right?
>> Right, exactly. Yeah, we want
that cross-platform capability to be able
to run .NET on commodity servers, if you will,
and Linux server said,
".NET Core implemented standard 1.0,
and that allowed us to sort of
open the door and say, 'You know what?
We have a lot of different implementations of.NET.
Any implementation that deals with
these APIs can target .NET Standard 1.'"
So then, we got 1.6, which brought
in a few more frameworks into the family.
Then, when .NET Core 2.0 came out,
that coincided with Standard 2.0,
and then other releases and other platforms like Xamarin,
and it just raises that.
It added 20,000 APIs.
>> That's what I heard, and this is really huge, right?
So, this means that finally,
now we have with .NET Standard 2.0,
I would say you can
create cloud libraries that you can really
use on client application as well,
such as WPF, such as Windows Forms.
>> Right.
>> And those are cloud libraries that you create,
that you can then use on Linux,
in a web application if you want,
or on Linux, in the console application if you want.
So, if you create utility, et cetera.
Of course, you can also use
those class libraries in Xamarin like we see here,
and then run them on iOS and on Android.
So, it's pretty impressive
in terms of cross-platform story.
It's quite an impressive story, right?
>> It is. In fact,
when I first looked at .NET Standard 1.0,
I ran into what a lot of people did.
It was just such a small API surface area.
With 2.0, I was able to take
a compression library from 2007.
>> Wow.
>> So, this was before people were probably even,
while they probably started thinking about.NET core,
but it was before that was even out.
By targeting .NET Standard 2.0,
it compiles without changing the source code.
You take that DLL, drop it on a Linux machine,
and it compresses files on that machine.
>> Yeah. That was sincerely cool.
So, I think basically what we can recommend
to people who are watching is
really take a good look at .NET Standard.
If you are using Portable Class Libraries these days,
you probably want to start thinking about moving
your code to .NET Standard
because this is really where Microsoft is going.
You can still create class libraries,
Portable Class Libraries in Visual Studio.
It's marked as Legacy.
That kind of should tell you something, right?
>> It should be a flag.
>> Probably a good flag.
So, people go to action,
really start moving your code,
if you can to .NET Standard.
If you have a PCL already,
if you have a Portable Class Library,
the move is pretty painless.
We will put in the show notes a few links.
I have a presentation that I gave,
which is explaining how you can do that.
I put in my NVIDIA library
to.NET Standard a few weeks ago,
so this is a good thing to watch.
Also, we have a blog on
www.blog.xamarin.com which is explaining
also a little bit the history of .NET Standard,
where it comes from, and so that can be
an interesting read for the users.
Any closing word? I think we
are reaching the end of the show.
>> Sure. The last thing I'll say is,
there's a lot of NuGet packages that are out there,
and not all of them are converted to .NET Standard.
Microsoft scanned the packages.
We can tell the portability based on the APIs,
and we found that 85 percent of
those packages are compatible with .NET Standard 2.
So, there's no reason not to retarget those libraries and
share them because it only
helps anyone maintaining the library,
because it gives you access to
more platforms that that library can be used on.
>> Completely. By the way,
a good tip about that,
we'll also put that in the show note.
There is also a Portability Analyzer
that Microsoft has published. It's a tool.
You run your DLLs through that and it tells you,
"That particular APIs that you're using,
you might have to change it."
But chances are, that
your code is just going to run really,
because with those 20,000 new APIs,
we have a great surface.
Cool. Well, thanks so much for joining me.
So, this was the first Montemagno-less episode
of The Xamarin Show.
>> Right, and I'm not James.
>> I'm no James either,
but I think we did a good job anyway. Cool?
>> We did our best.
>> Cool. Thank you.
Thank you for watching and
see you next time on The Xamarin Show.