>> I think it's all
happening in real time. All right. That was a terrible joke. I'm really excited because I've
been messing around with building mobile applications as
a real job for over eight years, and I never thought in my mind, that with just three or
four lines of code, I could create instantly-connected,
real-time applications. I never thought this
because I used to have to write all the TCP and
UDP code all myself, multi casting myself by hand, and it was terrible. Has anyone ever had to do that? Yeah, and you're all
like, "Yeah, I never want to do that again," basically. Sometimes you got to get down to it. But when we think about building
real-time applications, they really span all
the different devices out there, and that's where SignalR can come in. It's literally in
the title of this talk. So what I want to focus
on is how SignalR, as a service, what it
offers, what it does, and what it brings to
mobile applications, but also to your web apps or
any other type of application, and just how awesome our
cross-platform.NET story is. So today I'm going to show you
everything there needs to be known, humanly possible about
building real-time apps with Xamarin and SignalR
on conference Wi-Fi. That's very important.
Everything that you see here, conference Wi-Fi. In fact, we're working on
that roulette application, and it needed to push an update, did it over conference Wi-Fi, thanks a Wi-Fi debugging.
It was amazing. Really cool. So we're here
to talk about SignalR. SignalR is a service from
Microsoft that enables real-time communication
across different types of application platforms
you may be building for. SignalR has been around for a while, but there's a new flavor of signal are with ASP.NET Core coming out, and it's been re-architected
from the ground up. But let's first talk about what real-time applications are and why
they're so important nowadays. Well, for me, it's really
important because I'm traveling all the time or
on the go all the time. We need information immediately, and we want them on all
of our different devices. So no matter if we're on
the go with our tablets and our PCs or sitting at home gaming or we
just have everything around us as we're
constantly communicating, having that instant notification
is really important. It's really insightful to me when I'm inside of Teams
or inside of Slack, and I see someone typing, and I know that they're
following up with me, just as equally important when they stop typing and didn't
send the message. Why didn't they send the message? That's something that's also
very important because nowadays, not only is the start-up time
of our application important, but it's the things
and the interactions inside of our applications
that are ever so important. So it's fun to have
some nice animations, but I wanted to walk through a few scenarios that you may be thinking about for real-time and what
you can actually do with it. So, for instance, you might want
to build a chat application. Here, for instance,
this is using SignalR, where I'm authenticating
with Twitter, and as I start typing, it updates on the other side, has some information
about me in general, and I can type back and
forth into the browser, and I can get some
information about me here. You could do some other
things such as do private messages that come across, for instance, and send some additional information
across the wire. Perhaps you're doing
real-time collaboration on a whiteboard scenario, where on one side of the screen, you're actually coming
in at your drawing, and on the other side,
it updates immediately. This could be any application
whether it's a mobile device, a game, or a web browser. Some other scenarios
that are also important, when I sent my partner the FlightAware map of
where I was going and was getting real-time
information of where my airplane was on
her map, on her phone. It could just update, she could
see immediately where I'm at because that information
is publicly available. Now inside of mobile apps though, there is something that is quite intriguing that we
could do besides just saying the entire app is built
on a server-less process. What if we could take a single piece
of our functionality and really fine to it to give instant gratification
and updates to our app. So here, for instance,
on the left-hand side, I have a Cosmos DB entry, and on the right-hand side, as soon as I update it, it updates instantaneously inside the browser or inside of
a mobile application. This can extend to
absolutely anywhere though. Maybe you're running
a Raspberry Pi or a Netduino, because you can run real-time applications directly on those devices
communicating to anything. So you can imagine
how imperative that would be in an IoT solution. So from start to finish, already, we've seen web scenarios, mobile scenarios, IoT scenarios, and there's a lot more too
that we'll go through. The awesome part about SignalR, is what SignalR does, is it abstracts the common patterns that need to take place for
real-time communication, and the default that
it uses is WebSockets. WebSockets are
a really great technology. They've been around for awhile, and they're tried and true. However, not all servers and not all devices may handle
WebSockets gracefully. Some older versions of Android, for instance, or
maybe older browsers. So what's great about
SignalR is, automatically, SignalR will figure out if the
device can handle WebSockets, use that, else fall back automatically to Server-sent
events or Long-Polling. You don't have to think about
it at all, it just happens. So when we think
about the billions of different devices in the world, there are some use cases
that SignalR can handle. So the first is that all of these
here are just readily available. Perhaps I want to just
broadcast a message to every single device possibly
connected right now. We all got amber alerts earlier, and that's a use case for
real-time notifications along with some of
the other scenarios. They were broadcasting a message
out to as many people as humanly possible that are connected
to the service at that time. So that's the first use case
that I want to talk about, and here's how it works. The basis of a SignalR is
that there's a HUB process, and this lives somewhere, usually on a server. We'll talk about
the different scenarios in which you can host SignalR. Then you have your HUB, which is the base process. What it does is, it handles the connection
between the different devices. So once a device connects to it, the HUB simply says, "Hey, you're connected, and
I'll send you an event." What's great from
this aspect is that it automatically handles
connection management, it'll handle all of the
device registration, it'll send all of
these connected clients those messages simultaneously. We can even go down more finite into groups or specific
clients which I'll go through. More importantly, if we're sending
tens of thousands of messages, SignalR will scale gracefully
with increase of traffic. So now you know what SignalR does. The very easiest concept
of what it can do, how do we get it into
our applications? Well remember there's the HUB client, I'll say the HUB device, that is connecting
to all the clients. That is going to be
written in C sharp with ASP.NET as the SignalR HUB, or this magical SignalR thing that I'll get to
later that's part of Azure. Then all of your clients can connect via using
JavaScript, TypeScript, Java, or, of course .NET and.NET Standard across all
of your .NET applications, including your Xamarin apps. So what I want to first
do is walk through the easiest broadcast scenario
that we can do for SignalR. Every single one of my demos
are available on GitHub today. So I'm going to switch
over to my Mac, and that way, the AV guy knows, boom. Oh, look at that. That's graceful. All right, so I'm going to switch
over to my Mac really quick, and plug in some power
into here. There we go. Let's see if it pops up and
everything will scale all crazy. Oh my goodness. All right. Oh look good. Okay. So what I have over here, is everyone's favorite
Xamarin Application ever. It's the default, master detail view. But it gets the point across, that what we have here
is this a Xamarin App, and Android, and iOS App. Then what I've done is inside of
our Default Project template, we have add an ASP.NET Core backend. So that's what I've done. Now, normally, when you
go and run this template, you have to go and
your mobile Apps connect to it, either locally or you push that up to Azure or some other web back-end. Then you're pulling to refresh, you've submitted it to your ASP.NET Core and inserted
into your database, you have the pool again. But what I thought is what
if every time I added a new record into my item repository, that I notified all of my devices. No matter where I do it, whether I do it on the web or
if I do it from my mobile apps. Now, the cool part here
is that everything on the ASP.NET side is built
directly into ASP.NET Core. There's nothing else you need to
add for SignalR, its built-in. So how we enable that
is in our startup code. How many of you have done
ASP.NET Core development? [inaudible]. So there's this startup
configuration that handles all of the dependency injection
and IOC shenanigans. This is the startup if
you were inside your app. So it says I'm going to add MVC, I have some permissions here, I have some swagger definitions, and then I say AddSignalR. That's going to tell our services in ASP.NET that I want to
use SignalR service. Then I'm going to configure a hub. You can have multiple hubs
that do multiple things. Here, I'm going to say signalR, MapHub of messages Hub
which I'll talk about here in a second to /hub/messages. So I could have hubs/chats/messages/update/air
flight/blah-blah-blah/how many cups of coffee
I've I drank today, not enough, and you can have
as many of these as you want. So if we look at what
this message hub is, is a hub. But this is the most easiest hub,
it doesn't do anything. It's just a mapping for
where we can make calls on. So normally, what you'd
put inside this hub, and I'll show a more
complex sample in a bit, is all of the logic for updating, sending the messages,
receiving the messages, all that stuff, nut I
figure what I'll do. In this case, is inside
of our item controller. Whenever I create an item, I went to then send
something from my hub. So what we can do is, here, I'm passing in my item repository, and I can also put in IHub context. So I can get access to
that hub in my app, and that's what it is right here. So here, I have normal get, send post, and all that does. What I'm going to do is come in, and I'm going to take the item that's passed in and created and
added into my back-end. I'm going to serialize it
as JSON and I want to send that to all of my connected clients. So here, when I type
in await Hub.clients, I can get different access to
clients or groups connected. So those are the things that I have. When I go into.clients, we can see I have.all for instance, so I can send it to everyone. Then I'm just sending
a JSON package just as almost if I made an HTTP request. I say to all my hub clients, send this JSON across, that's it. That's my back-end literally
like four lines of code. Now, Azure or SignalR
is configured in my back-end and I'm sending the
message with this key of new item. So everything in SignalR
is key value pair. You can have multiple values
that you send across, but you're always sending a key with a bunch of data back and forth. So let's look at
the Xamarin App here. Our Xamarin App is pretty standard. But what I've done is I've added
the ASP.NET Core SignalR client. It's a really funky name
because it says ASP.NET Core but I'm adding it to
my Xamarin App, and that's weird. But it makes sense if
you think about it real hard for about four months. Because I think I
just got it on stage. It is the client SDK for SignalR which most likely lives
inside of ASP.NET Core, sometimes. So it just bear with the naming
it's a NuGet package, [inaudible]. So here's what we're going to do is, what I want to do is every time
I get that new item message, I want to add it to my list. So to configure SignalR,
it's crazy, easy. Remember when I had a hub
before on my messages Hub, well now, I have a hub connection, for my mobile app client. I'm going to make
a connection to that hub. What I do here is come down here
and I create a hub connection, which is just a URL
like we've always used. It's a place on the Internet
where that hub lives. Now, in this instance, this is going to create
a connection builder, I give it a URL, and I build it. Here, when we go to declaration, we can see what I'm doing down
here is I'm passing in for Android the specific
local IP address, or local host if it's on iOS. So this is the special IP
for the Android emulator. So that way, I can talk here. If I publish the Azure, I would just put in my URL. So then, once we have that setup, we have these really cool methods that allow us to subscribe to events. If you were just in
the reactive programming, it is like that. It says, "Hey, connection
on whatever you expect." It could be an item, it could be a string, it could be multiple items, it's T-based so you
could expect a string, a Boolean, item for instance back. When I'm expecting it to be new item, and then it's going to give me a NewItem in string so
it's templatized here. Now, since SignalR is coming
back on who knows what thread, who just due to I mean it's
some magical thing that's listening, I want to add a new item
into my list. So of course, I'm going to
use Xamarin essentials, and on my main thread, I make sure that I invoke
this on my main threads, so I don't break my application. So what I do is I take that string, I deserialize that item, and I make sure that
the item ID doesn't exist. Because if I push it from one mobile app that's
already added into the list, I don't want to add it to itself. So only if I don't already have
this item in my list, insert it. That's the only logic I need to put in to start listening for events. Now, I need to start
the connection though. Now, this is demo where,
not best practice. But what I'm doing here is
the very first time I load my items, I'm doing a very simple call here. Look at this, terrible code. If I've connected once
ever, then don't worry. If I've never connected, will say start asynchronous
to that connection, and then I'll say connected=true, and then I'm just going
to pop up a dialog box. So literally, they're StartAsync,
StopAsync, that's it. Whenever I have my builder, build my connection, listen to stuff, starts stuff. That's it. So now, what I'm going
to do is I'm going to first start up my back-end. So here, I have the terminal
open right here. Here we go. I'm going to say .NET run. I'm going to run my ASP.NET Core
Application in my back-end. So say run, and it should
build up. There we go. Warnings, whatever. All right. So it's on localhost. Let's open up a browser. Come on Mac, book adorable, there's a reason that they
stopped making you. All right. So I'm going to say localhost 5,000, and I have this swagger definition. So inside here, I can try on my API. When I execute, I'm going
to get some items back, so some three default items. Just cool. So now, what I'm going to do
is run my mobile apps. So I'm going to add debug here. All my code is in place. I'm going to compile on my project. In Visual Studio for Mac, I have it multi-deploy. So this will deploy to my iOS and Android emulator
at the same time, and they're going to be
listening on the same address. Cool. So this one's connected, this SignalR, it's connected. I have those three items back. Android still booting
up. Give it a second. There we go. It's
going to connect up, and it's connected to
SignalR. Gets the items back. Perfect. So now, what I
can do is come over here, and I'm going to do a post. Remember, whenever I post a new item, it's going to send that
message to SignalR, from SignalR to the clients. So we'll say try it out. Here, it's just the default
of string string. Let me go and move these over so
you can see, I'm really nice, and I'm going to say "Execute", and they just update auto-magically
right inside there. That fast. You can see, I added a random number. So you can see just how fast
it's coming across SignalR, with literally no code to get
that update automatically. But what's great here is
that if I hit "Add" for instance on one of the devices
and I give it an item name, and I'll say new. Well, my emulator's
great. There you go. It save immediately, right
over there. Just pretty cool. Now, it didn't add it into this list because I
insert that at the very, very bottom on Android, because that's how
the default one does it. I inserted from SignalR on the top. You can see how fast, I
didn't have to long quote, and have to query the server, it's happening in real time. With literally, like
10 lines of code. Awesome. So when you think about
real-time, think about that. I don't need to have
a real-time application that the entire thing is real-time. Think about one or two use
cases where maybe this data could be a lot better
if it was updating live, and how I can integrate
that into my apps. Let's head back over to my PC
as I disconnect my Mac. Up? No. There we go. He's on It. He's awesome. Cool. All right. Beautiful. So that's
the easiest use case that I could possibly
think about for a V1, just showing how easy and
simple it is to get started. That's that same exact code. Is it coming across? >> Not yet. >> Not yet? All right. Let me
back out PowerPoint and back back in just in case. Just how easy it is to do something such as just sending
a notification across. It's easy to do. If
you already have an ASP.NET website, boom,
you're good to go. Now, if you don't have
an ASP.NET website, I'm going to show you
how you can easily integrate this into other services. So we talked about
this broadcast, all these device broadcasting them out to
everything humanly possible, whether it's a mobile device or not. But we can go a little bit granular. For instance, maybe I only
want to send to users. SignalR can handle
group-based notifications. So here I can say "Only
send it to anyone registered in the Seattle
group, " for instance. Or maybe only people
on an iOS device or an Android device. Which is nice. Or you can target
even more fine grain, and say "Only send a message
to a specific user." Every single connection
to SignalR generates a unique client ID for
them automatically, that's register that
you have access to. So you can send that
information back and forth. So if we look at how we can make
something even more complex, different scenarios
here, we can think about it in not just a broadcast. We can even do
broadcasting from device, because while the Hub
itself can send messages, it can also receive messages in
real time. This is also unique. So here, we can send a message
from a laptop or a mobile phone, and then we can send
that message back out. This would be a really
great use case for a chat application because you can't do real time without
a chat application. So I've built a little chat
application to show how we can not only broadcast from
a device to other devices, but also do them in a group. So here's what we're going to do, we're going to head
over to Visual Studio. Here is my app, inside of our previewer, our updated previewer
with design time data. So here, for instance, I have the connected clients up top, so whoever's connected, I
have some information there. What we can see up top is that
I have a collection view, and I'm using an array of users. So I'm not specifying a string. I'm actually using
my real data model here to pipe in some design
time data into here, and then I'm using frames for days. Just every day a frame, basically. If we need a circle, just
use a frame. Frames all day. I have another collection
view down here, and I'm using a trick by one
of our MVPs. What is his name? It's called the 180 by 180
by 180 trick. It's amazing. If you want things to rotate
from the bottom, you take it, you rotate it, and then you
flip it again. It's bananas. So I have another
collection view with yet another data binding here for
design time with the messages. I always like to use the previewer and put a little spinner up here. How I get that running is I use design time to show it is
running and is visible. So this is my layout that
I'm going to use here. So that's the application, and what this is going to
do is multiple things. It's going to show me
a list of rooms that are the groups that I can
subscribe to and then it'll enable me to subscribe to a group and send
chat messages to that group. So this means that
our back-end Hub needs to be a little bit smarter than
that blank empty shell. So I'm going to go into
this startup code, and what we'll see is we just
have an ASP.NET core application. I've added SignalR here. Let's make this bigger again. That's about how big I code at home. Then, down here, I say "Add
using SignalR and my route. Before I had "/hubs/messages",
and this is my Chat. Now, my Chat is going to do
a lot of different things. It's going to handle being able to send subscribing a user to a group, It's also going to
be able to send and receive messages from that group, and also signal when
someone has left the group. So there's a lot that it can do, because you want to get
notified when someone leaves and enters so you can
show that in the UI. So inside my hubChat, I have a few different methods. It's going to look very, very
similar to what we just saw, but instead of having
this Ihub contexts, I'm inside the Hub, so I immediately have access
to everything inside the Hub, like groups, the clients
that are inside of there. So if I look here, and if the first thing I want
to do is tap on a group, a chat room, I'm going to
add myself to the group. Now, this user that I'm passing in is just a username that I specified. So James or Heather or
Mattie, for instance. It's got a "my unique
identifier" for me in the UI. When I add this, this will be called
from the mobile app, it'll pass in the group. What we'll see is that I'm
using context.connection ID. Remember when I said that
SignalR will automatically generate a unique user ID
on every connection? That's what that is. So if every single one of you
here calls "Add to Group", it's going to generate
a unique ID for every single one of
you, every connection. Which is cool, you don't
have to worry about it. Now what's nice in this is, I'm
saying groups just internally, it manages that group for me. So I add this user with
that connection ID to the group. Then what I do here is I say "Clients in group with group name send a message that
this user has entered." So now, if a bunch of
people are in the room, they'll get a notification when someone has added
themselves to the group. Similarly, exactly the same
from removed from group. Same information, except for I
say "remove from group async", and then I send a message
that they've left. Then, honestly, besides that, all I have to do is have
another method that I can call from my mobile apps that says "Send message
to a specific group." So notice here we're going to send in a bunch of different information. We're going to send the group name
that I want to send to, the user name, for instance, that maybe I
want to get some information, so I need to broadcast
that to everyone else, and then the message. Now, I don't care about the
connection IDs at this point. I don't have to maintain
a list of connection IDs, because SignalR in the back-end knows that I've added and have removed
these specific connection IDs, and that's who I'm going
to be sending messages to. So really the back-end code- 30 lines of code and I just wrote
a chat application? Awesome. So let's look
at the back-end here. Again, I have an iOS
and an Android app, and what I can do inside of here
is create a Chat, a Chatroom. So over here, what I'm going
to do- is this where I'm at? No. I put it in here. Even better. The code is
not even in my mobile app. It's in a different.net standard library because that's how we do it. So I was like, "Dammit, where's my code at?" It so abstracted in how
SignalR for.Net can work, is it can work with every
single.Net application. That's why I thought that every good Chat application needed a great mobile client and
a council application. So I wrote a real great program,.CS. It's terrible. It's
just really bad code. Don't write this code. I wrote this code because I
wanted to test it locally. So what I have here is
a council app and my mobile apps, and they're sharing the same.Net
standard library that will send and receive messages from SignalR because it can
be used in any.Net app. So what I've done here, is I've specified basically
just some events that will occur. So any mobile app, any other application can
subscribed to events, instead of subscribing directly to SignalR. So I have
some message event arguments. The arguments here's are pass in
a message and a user, basically. My ChatService is similar
to what I had previously, except for any of my clients can register for an OnReceivedMessage, OnEnteredOrExited, and
OnConnectionClosed, so different events. Then I've isolated this code
into the single ChatService. So I have a hubConnection. I have an initialized here, and what this does is it will detect basically IP addresses I need to use, if it's HTTPS or not. Else, it'll just use
whatever URL I pass in. I'm going to use that
very similar code, hubConnection builder, do it with
the URL, whatever I'm creating. Of course, here I'm doing the IP, port, hub, Chat the same URL. What's cool is that we
did have, for instance, that hub on, but
there's also OnClosed. So for instance, if my mobile apps, if I lose connectivity
and I come back up, I want to make sure
if I've disconnected from the service, I reconnect. So here what I can do
is I can simply come in and wait a few seconds
and disconnect, and I could give up after
so long, for instance. Here, I'm just trying
forever because it's demo. That's not best practice,
don't do that. Or maybe do that, it's your app. You should life your life.
It's okay to be yourself. I'm not going to tell you what to do. Then, that's it. So
now what I do is I simplify these messages down
into these connections, which is exactly what we saw before: receive message, entered, left. Now, what I do is I pass messages back to my mobile app
that they can subscribe to. This is what you want
to display in your UI, this message, this user
entered, this user exited. I just really simplified it. The other code that's inside of
here is some connection code. So again, ConnectAsync make
sure I'm not connected, start, disconnect, disconnect, and
I just dispose asynchronously. So when I've left I
dispose asynchronously, get rid of everything. Then I have a few methods to
send messages to the hub. Remember, before we were saying "On"? Well, it's the same exact code or very similar ode to what we sent
from our back-end code earlier. Here, whenever I want
to join a channel, I'm going to send a message, add to group with the
group and the username. When I leave it I'm
going to notify SignalR, that I want to remove myself
from the group and, boom, I've sent those messages up, SignalR receives it, and sends another message out. Then in the back-end here, I have a way to send a message. So again, it's really just
sending messages back and forth. In this instance, I can do SendAsync which does not await a response from the server. InvokeAsync, this one does wait
for a response from the server. So when I send a message, I really want to make
sure that it was sent. Then I have a little GetRooms. Now I could have added
this into my back-end, but he's hard coded it in here, and these are the rooms
that I want to use. So what I'm going to do now, is we're going to go ahead and
spin up this back-end service. Did you know that you can do that? You can type in CMD. Did everybody know that besides
me up until three weeks ago? Because when you do that it opens the command prompt right
there, it's amazing. Yeah. I didn't know that
either, it's bananas. So I'm going to run my back-end. It blew my mind, I was like, "What?" Because you know what I would
do is I'd have CMD, copy, CD. There we go. All right. So here it is, it's running locally
on my port, just sitting here. Then what we're going to do, is we're going to
run our mobile apps. So here's our chat room, over here. If I go into the Chat View Model, what we can see is that I have a few different properties
inside of here, some commands. So the UI can interact,
send a message, connect, disconnect, and this
is standard Xamarin stuff. So inside of here, I have
an observable collection of chat messages of users, and I just started
subscribing to events, and I don't unregister because
I didn't go to Shane's session. So I'm just registering, who cares, just live your life. So I register and then I'm
just basically adding, removing user interface from here. So whenever I go in
and I send a message, I make sure that it's
on the UI thread. I make sure that this user exists, and then I insert it. Whenever I remove the user, I remove that user, I add the user from the list, and the same thing here
for sending a message. Whenever I type send, I send the message with the username. So here I have
my mobile app, over here. Let me make this a little bit bigger. In my profile I'm using
Xamarin Essentials just to save this local IP address
on my username, so I can use it everywhere.
So this is Localhost. What I'm going to do is just
go into the Xamarin group, and there was an error that occurred. That's good. I can see that nothing is
happening here, that's good. An error occurred. Well, let's debug it. When in doubt debug it live
and also when you debug, you can just have
a little jingle like that. My assumption here, this is running correctly, HTTP. Yes, let me just make sure that I did this because it worked
10 minutes ago. Localhost, yes. What we'll do, is let's just make sure that in my chat service I'm
connecting on the right URL. Let me put this here, there we go. Let's connect to
the Xamarin chat room, my URL is Localhost HTTP.
Yeah, that looks correct. No, that is not correct. It is not correct because
the IP for Android, like we all remembered earlier, was 10.0.2.2, classic James. Perfect. All right. So let's do this. So we're going to do
10.0.2.2. Is that it? Yes. All right. Perfect, and we're
connected, we did it. But I have no friends
to communicate with. Well luckily I have a console application that can communicate. Wouldn't that be great? So what I can do here is CMD
that, .NET run, check this out. Awesome. How do I make that bigger? I don't even know how
to make it bigger. Control? No, I don't know. Now this is Localhost
connected, do it. Yes. Now, I get my rooms. No, here we go, let's
put this over here. That's better. I'll zoom in because I love to
zoom, everyone knows me. Xamarin. I'm in the room. Leave, I'm no longer in the room. I'm in the room, no
longer in the room. I want to be your friend, and I'm in the room. Now, check this out. To prove it to you, I'm in the .Net room. Leave, back in the Xamarin room
because I'm in a group. Wow, It works. Awesome. Well what's cool here
is I can now not run it locally, and I could maybe publish
this up into Azure. So what I've done ahead of time, is I have published this
just to an App service. It's running, it's an ASP.NET core application running
up inside of there. What I've done over here is I've
gotten to my configuration, and the only thing I have to do is enable WebSockets,
that's basically it. Now this will be
running on HTTPS which is nice, automatically for me. So Localhost will be
just running HTTP, I'll run it up on HTTPS. So what I can do here is
I could come out of here, and if I go into my log I'll see that the Website is
Xamchatr.AzureWebsites.net. So here I'm going to say
Xamchatr.AzureWebsites.net. Go over here, I'm going to go into this room where I have
connected into the back-end. Sad. Well, it's because
it's on local host. Now, what we're going to do, is we're going to look
at my beautiful code. Exit, perfect. Exit and then we're
going to dot.net run. Of course, its exit. Why
wouldn't I put it, exit. Too hard to control C.
So I'm going to say Xamchatr.azurewebsites.net
and now my console is going to connect up
in the Xamarin room. Boom, awesome, amazing, and
then what I'm going to do, is I'm going to go on to
my mobile phones that are also on conference Wi-Fi, where I've installed
the application here. What we're going to do is not install an update from
hobby app, that would be bad. Let's install this. Let's go to XamChat. There, hi, and this is how I do this in real life
and I come in here, I have the app here
and I'm like, "Whoa". Here we go, this is how people send text messages across every single
one of their devices and boom, I've just created a real time chat communication app,
right there, boom, awesome. I have six minutes, let's talk about
a different way of hosting our SignalR client because maybe you don't have
an ASP.Net website. Well, we have something
called Azure SignalR Service. What's great here is obviously
with SignalR for ASP.Net, you can solve host app, put it anywhere, any Cloud. But what happens when you
really really want to scale? What happens when
it's not just me and my 18 tests devices
talking to each other? What happens when I create the best next chat
application that's going to take the world by storm and
tens of thousands of users use it? What happens when I need a
100,000 concurrent connections? That's where Azure SignalR
comes in because it can only scale out and ASP.Net Core website
to launch with the SignalR. You also down want to
bug down your website, so Azure comes in and it will
handle everything for you. What it does is that
it kind of sits in between you and your app server, to handle all of the connection. Everything possible that you want for your up to tens or hundreds or thousands of
concurrent connections. So it's that gateway in between. Now what I love about this though, is that what we can build
for it, are Azure functions. Azure functions will be our gateway
instead of the existing ASP.Net Core back end and it will handle all of the
communication back and forth. I can then use anything
that Azure Function uses, such as PowerShell scripts, all TypeScript, JavaScript, C#, Java, all the things. Publish it to Azure SignalR Service and then any of the clients
and connect to it. It's really super simple and
it scales out on demand. So you literally go into the Azure
portal, say "SignalR Service." Fill in a few informational things, select "Free" because
everybody loves free. Well, that's a cool animation and
then you're going to obviously select a "ServiceMode"
that we call serverless. So I have one more demo and in the last three minutes,
I'll show off, which is how we can use
Azure SignalR Service, combined with Xamarin, the .NET SDK, and Azure functions to create a real-time translation application from my browser to
my mobile apps, scaling this out. So what it will do is in the browser, I have a Vue.js application that I did not write because I have
no idea how Vue.js works, so my good friend, Anthony Chu, wrote that end of it. It's going to in the browser, take in my microphone
that I'm speaking in, translate it using
Azure Translation Services, publish those translations
to Azure functions, which will then send those to Azure SignalR Service
that will [inaudible] out all of the translations
to anyone that's listening. So let me show you
what this looks like. Over here, I have a
Vue.js application. It's a bunch of
crazy JavaScript stuff. But I want to show you is, what's really kind of cool about it, is that I'm using
a translator API here, and I have just a simple way of
posting these to my back-end. So my Vue.js app doesn't
really know anything about Azure SignalR for broadcasting. It's just going to use the
translator service from JavaScript, bring it in and handle it for me. I also have a way here of using the SignalR client to receive
messages in JavaScript. So here I can pose, I can get the list of languages
and then here it's very similar. I'm going to create a hub client,
build just JavaScript. Then what I'm going to do is, stop debugging and I'm
going go over here into my Captionr service and I have an Azure Function
that's sitting here. What this does, is it
first starts out a way of negotiating and registering. Our ASP.Net hub handled that before. So I create a simple
SignalR connection to negotiate and that's what my clients are going
to communicate with. What's cool then, is that I have
different RESTful endpoints, that I can basically get a list of languages that the service supports. I can then also come in and select a language and what this does
is with Azure Functions, it can say, SignalR use HubName captions and I can then send and receive information
to that group automatically. So here's what I'm doing is, I'm saying for this group, add the user that's passed
in here with a group name, which is the language and a specific
action to add or remove them. Then whenever some one posts
new languages or translations to it, I add those in here and what
I end up doing here is, I loop through all of the languages
that I've received and then I send a SignalR message with
the new captions out to the clients. Then literally inside
of my mobile app, what I'm going to do here is
something that I did previously. I have a hub connection. I come in, that's HTTP client. I create a new Hub Builder. I have a new caption and whenever I get
a new caption, I display it. So here's what we're
going to do, is I'm going to come over and I've created the browser over here, I have one on each side. So this is what it looks like. I'm going to start a session over here and I'm
going to start talking into it. Now, this isn't doing
anything magical. This is just whatever I'm speaking, is putting out stuff
over here and then I have a session that's going to
connect to it for Captionr. It's going to call into
my Azure function, and get a list of languages, and it's going to start outputting this information
basically in real-time. Then what I can do
is, I can say, "Oh, I would really like that in Japanese," and it's going to
translate it into Japanese. Then what I can do is, I can come over into
my mobile application, which is now speaking
to that same Azure back-end and SignalR client and
I'm going to say "Get languages." Now, my mobile app is speaking back. Now, what you can do on your device, everybody take out
their device right now in real time, and what
you're going to do is, you're going to go to this URL
aka.ms/xds-captionr, right there. I will leave that up. As I continue to speak,
I'm just going to go in, and I'm just going, you know, go over to Korean for instance
and just start doing this. What you're going to do
do on your phone is, you're going see
that same exact website and everyone inside of here should be getting captions in real-time of everything that I'm saying into this. I'm literally just talking nonstop so the translations continue to come
up and now what we've done is, we've now made hundreds
of real-time connections to the Azure SignalR client back-end, connected from mobile apps
from web clients, all using those
different graceful ways. I hope it works because I don't
know what any of you are seeing right now and no one's saying
anything and that's awkward. So hope it works, yes, did it work? Yeah, awesome. You can get all of
this source code as well. So what have we learned, now that I'm two minutes over. SignalR is awesome. Thank you so much. I'll be around for
questions outside as well. [MUSIC]
