Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Daniel Jacobson. Hey, Daniel. Hey, how's it going? Good, how are you? I'm good, I'm good. Daniel's a Program Manager on the Visual Studio team. That is correct. And you are an expert in building Windows 10 apps. Sure, yeah. Absolutely. There's an app that you showed at .NETConf on Channel 9. You also showed it at one of our internal technical events that I thought was just so cool that I wanted you to come on the show and talk to us about building Windows 10 apps using the Universal Windows platform in the context of this actual application. Because I think it really kind of drives home why people should be interested in this and what the possibilities are. It's not just about the surface. It's not just about the phone. So you know, the Universal Windows platform runs anywhere Windows runs. And that opens up some really interesting possibilities, such as the app you're going to show us. Yeah, so the real beauty of the Universal Windows platform is being able to write one application and run it on any one of the Windows 10 device families, which right now includes IoT, as you see here, desktop, mobile, Surface Hub, Xbox, HoloLens, you name it. So one app runs everywhere. And other things that no doubt are being worked on that we're not allowed to know about yet. Yes, probably. Who knows? So the inspiration for this application actually came to me when a friend approached me saying that they were interested in starting their own small business in Seattle, a coffee shop, if you will. Of course, coffee Seattle makes sense. Yes. So what they wanted to do to optimize their chances of success being a new business was be data driven, be smart about the way they run their application. So I thought this is a perfect use case for Microsoft technology. I could build Universal Windows platform applications that target multiple devices, use .NET technology and Azure and pretty much build an end to end solution that would help them out. So what I built here is a device that will help determine when someone enters or exits their store, then send an event to an Azure hosted ASP.NET web application, which will be listening for those events, then store it in a database. And then when they wanna review that data over time, they can use a desktop or mobile application to actually look at graphs, see how is my store trending, how many people are in my store at different times in the day, what's the busiest day of the week, what's the busiest time of the day. That way they know when do I need a higher help, what days, what times, how successful are the promotions that they're running, do they see a spike in traffic when they run promotions, et cetera. So that was the idea behind this. And as you can see here, the app design has quite a decent plethora of parts, but it's actually a relatively simple application when you get into the nitty gritty details for all of these apps. So the IoT device really only has one class of code that actually does anything. Same with the Azure hosted web API. It's really just a single class that does everything and it's like 200 lines of code. And then the client app is a little bit more involved. We're not gonna go through all the code, but I'll point you to the GitHub link after this so you can take a look at it yourself. So the way this is gonna work is on the IoT device, which is, we'll spend some of our time since it's more unique in modern application development era. Phones have been around for quite a while now, same with desktops, but these are up and coming. So what this is gonna do is based off of these devices, I'm gonna fire an entry or an exit event saying someone has entered my store or someone has exited my store. And when that's done, it'll send an HTTP request to my Azure hosted web API listening for a post response, which will then write the event information to a database, including what type of event is it and at what time did it occur. And then it'll actually send a push notification to the device running the application. So an example here is Sam in the back, it's a small shop, I'm doing inventory work, or I'm doing bookkeeping, I'm the only one working at the time. Someone walks into my store, no one's there to greet them, well I'll get a notification instantly saying hey, someone has entered your store, you better go take their order. It's another neat way to reduce the number of people I need working. Last century you just have a bell ring. This is the modern bell, there you go. Who needs a bell when you have smart phones. And then finally when the push notification is sent, the client at the data visualization app that has some graphs is notified to update the number of people in the store and then it refreshes the data. Cool, yep. So I guess we'll just go ahead and get started. Yeah. So in Visual Studio I have a solution that I've already pre-populated with some of the information. I'm not gonna spend too much time on the ASP.NET application but as I mentioned this is hosted on GitHub and I'll link it at the end. But what I wanna show with the ASP.NET application is how easy Visual Studio makes it to publish it to a live running web app. So here's my API, I'll look at the one class that I've actually modified, most of this is from the template. But here's my single controller of interest which has some metadata about my Azure services, these are just keys and other private information that's all obfuscated from the code through a resource file. Then I have two methods of importance, Git which is just gonna get a list of all the documents and Post which is going to post a new document. So it actually takes in the parameter my custom event from my portable class library. So this is actually shared code and then it writes that to the database and that's pretty much it. So two classes, you can find those online. So is keys hard coded in the code somewhere? Yeah, so keys is in my portable class library and a resources file. I don't wanna show that to everyone because then I can mess with my services. So what I'll go ahead and do is show you how easy it is to publish. So if I right click on the application itself and I have the web tools installed, all I have to do is find publish right here. I sign in with my credentials which I've already done so it should cache it. I can see my profile so I would select Microsoft Azure App Service. It would populate with all of my services, select the service, okay. And if this was a production environment I would just hit publish, that's it. But since I wanna actually debug this later I'm gonna go ahead and change the settings to make sure it is debugging ECPU which I did that before so. I'll hit publish and that's it. So now this is actually gonna send this code to my live running ASP.NET web application hosted in Azure. So just to test that as soon as it finishes publishing we'll debug it real quick. Make sure this is working before we get into the UWP applications. And while this is going the reason I wanna focus on this one first is because as you can see both the IoT device and the data visualization app have dependencies on the Azure app, right. So the IoT device is reading to the web app. The client app is, oh sorry got that backwards. The IoT device is writing to the document through this cloud service and then the client app for mobile and PC that's visualizing the data is reading from it. So Azure or ASP.NET first and then UWP. Published succeeded. I can see now in my browser here's my running application. So what I wanna do now is actually attach the debugger to that and make sure it works. So I'm gonna press a break point on the post event. Go to cloud explorer, another tool within Visual Studio. I don't have to leave the IDE. Navigate to my web apps, shop analytics service, right click attach debugger. And then that'll try to find the live running process to attach to in my Azure service. So it'll launch the service and if I return to Visual Studio once I see the break point is ready to go I should actually be able to send a post method to my live service and hit this break point. Make sure it's working. So I'm using another application called Postman which is just a simple web debugging tool that enables you to send HTTP request to any website you want. And what I have here is a prefilled out body. So I'm gonna send an event type, an event to my live service that is event type of true which means someone has entered the store. And I'm gonna send it for today which it is September 1st. It is. So let me go ahead and change this. Oh, if it will let me. That's interesting. Post body. Oh, that's why I was in the wrong one. September 1st. And this is 8 p.m. global time, so 20 o'clock. I will hit send. I should hit the break point. I hit the break point as expected. It is loading the information. So now I can actually take a look at the variables that are being passed in. So new event, true event time. You'll see September 1st, 20 o'clock. I can continue to execute this code. And now I should actually see a push notification on my device. So this device had been previously registered for the push notification service. So even though the app isn't running, the data visualization app isn't running because I had run it in the past, I'll get the push notification. So what that means is if I've got my Windows 10 phone and I don't have the app up and running but someone enters my store, I'll still know that they're entering my store, which is pretty cool. So I'm pretty confident that's working now. I'm not gonna worry too much more about the ASP.NET application. Let's actually build the UWP application now. So one thing I'm gonna do is actually continue to attach the debugger to this running service and I'm gonna build the IoT app in another instance of Visual Studio. You'll see why in just a bit. So let me open another version of Visual Studio with the solution open. There we go. And I'm gonna actually start from scratch. So I'm gonna add a new project to the solution. I don't have an IoT client project yet. So I'm gonna right click on the solution. I don't need Cloud Explorer since this is a client app. I don't need to worry about this controller anymore. Now I'll minimize that. So let's go ahead and add new project and I will just select blank universal Windows platform application and I will call it IoT client. So as soon as I create the project, it lets me select my target platform version. In this case, I'm gonna choose the anniversary edition. I like to play with the latest and greatest stuff. I'll hit okay. So to get started with this app and for those of you who have worked on IoT devices before, what you'll recognize is a lot of the code is just boilerplate code that essentially defines where all these devices are registered on the IoT device and the breadboard so I can say, I know this device is here. I wanna communicate with this device. Is it an input or an output device? It's really not any logic. It's just kind of getting everything set up. So I'm not gonna write that code. That code's boring. I do wanna write the logic. So what I'm gonna do now is navigate to the main page of my application. Whoops. That's the wrong one. And I'm gonna include that code. So let me go ahead and find that code. Desktop snippets. And I'll walk you through what this code means. It's just not as exciting to write it. Cool. So let's start at the top. I see a lot of squiggly lines. It's cause I'm missing some references. So to start with, keys as I mentioned before is in my portable class library. So I can add a reference to the same portable class library that's included in my ASP.NET application. I'm sharing resources across both apps. The next thing I will see is missing is GPIO pin. I can hit control dot to add a reference to the class. If I go further, HTTP client is missing the references. I'm just gonna resolve all my references. So GPIO, what's the one up here? Keys. They have to add a reference to the portable class library. So GPIO status is actually not something I can resolve immediately. What this actually is, is representing a text block on the UI. So because it is just a Windows 10 application, in order to help me debug that I'm doing everything correctly, I just added a text block to the UI of it. So let me go ahead and navigate to the XAML. And for those of you familiar with XAML development, this is just a XAML app. I will add a text block. X colon name. Whoops. Equals GPIO status. Beat the designer. But that's all right. Horizontal alignment equals center. Vertical alignment equals center. And then I'm gonna make it really big so we can actually see it. 72. And now I should be able to reload the designer. There we go. Now it loads since I closed my tag. So I'm not gonna see anything here yet, but when we run the application, you'll see that. So for a return to the code behind, that resolves down, no squigglys. And all that remains is two event handlers. And I'll explain those in just a second, but that's what makes IoT development with Universal Windows Platform really easy. So I'm just gonna create empty methods to handle those for now. And let's take a look at what this is doing and then just deploy it and see what happens. So if I go to the very top, the first thing I'm doing is defining the base URI for my Azure Web API. And this is essentially going to be used to send the post message. So I'm gonna construct my HTTP client object with this as my base URI. And then when I send the post message, it knows, okay, target the right live running servers. These pins, if we take a look at the schematic for this device, are just actually mapped to pins on the Raspberry Pi. So you can find diagrams for the specific IoT device that you're targeting that'll have a pin mapping for all of the digital devices that you'll be connecting to it. So if I take a look back to the code, five and 17 refer to the pins for my sensors. So that's what we have here. So that's what we have here, yeah. Connected to a. Red board in the middle. And then the breadboard has wires connecting to the Raspberry Pi device, correlating to those pins that I specified. So the black wire here is ground, red is hot, so it's the voltage. And then the four colors are just different digital devices connected to the pins that enable me to control them through the app. So for somebody who is a good C-sharp coders done, built apps, it hasn't really played with the Raspberry Pi. How long does it take to get to the point where you could wire up sensors like this? Like this? Yeah. Probably a day, maybe two. Okay. So I built this in an afternoon and the only previous IoT experience I had was Arduino based, it was not UWP. So you don't have to be an electrical engineer done soldering and stuff in the past, right? The commonality that all these devices have is that they're all just digital devices. They all behave similarly. So even though I'm using an IR beam sensor here, it behaves just as a button would. I mean, it's gonna have a value of zero or one depending on the state of the device. So if it's a button and it's pressed, it'll have a different value than when it's depressed just like when this is covered versus when it's not covered, it'll have a different value. Okay. And is there good introductory material on how good... Yeah, let's actually show you where that is. So if I just search for Windows 10 IoT Core on Bing, what I will find is tons of documentation. So if I just select learn about Windows 10 IoT Core, there's really great information about what it's like to develop for these boards, including examples that people have built. So an air hockey robot and then some tutorials as well. So if I click on documentation and I still get the samples, Hello Blinky is essentially the Hello World of IoT development. So I could select C-Sharp, C++. And does it show you how to connect everything together? Okay.  And here's the pin mapping that I was referring to before. So this is actually the same board that I have. And as you can see here, GPIO2 and GPIO3 are just the numerical pins that I'm referring to here. So 5, 17, 4 and 6 are the ones I'm using. So 17, 5, 6 and then 4 I think is here. So all in the same set. Yep. So it's not too difficult. So that's what those are referring to. Those are just the constant integers that define where I'm plugging those into my Raspberry Pi. Now these are the objects that are actually going to represent those pins. And then these enter and exit volumes are going to be used for the actual logic of the code. So we'll explain that in detail as I'm writing the code. And then client is my HTTP client. That is going to be used to send my HTTP web requests to my live running service. Finally, the last thing you need to do is actually initialize the GPIO controlling. So you'll pretty much see this method in any of the tutorials you go through for an IoT device development. But once you have all the GPIO pins determined, first you make sure that a controller exists on the device. And what this means is if I were to deploy this application to a desktop or a phone, it would hit this line, hit this if statement, and GPIO would in fact be null. There's no GPIO controller on my surface. So then it would return out of the method. Yeah. At least nothing that I can control. So then it would send, there is no GPIO controller on this device and my application wouldn't do anything. That's it. So nothing would crash. I'm only using the universal API set, meaning I don't have any platform-specific APIs. Everything is just common. And then I'm actually opening the pins for those four sensors. So as you can see GPIO pin, I'm defining the sensors and opening the pins. So after that I need to say, is it an output device or is it an input device? So these LEDs are output devices. I cannot interact with them. The value's never gonna change. I can write a value to them. I can say it's on or off, but I can't read anything from it. So when I set the drive mode for the lights, I set it to output. And then the sensors are the opposite. They're gonna give me a value back when I cover it or uncover it. So those are input devices, just like a button would be. After that, the debounce timeout is really just to filter out any noise from the IR beam sensors. So for some reason the value changed for 50 milliseconds really, really quick, like unregisterable, something that was undesirable. It wouldn't actually cause anything to happen. After that I just create value changed event handlers. And that's really what IoT programming is all about. When something happens, the value is going to change. I have some sensor that changes the value and then I respond to it. So what I wanna do is I wanna place breakpoints on both of these and deploy my application to this device. So first I'm gonna make sure it's my startup project. I set a startup project. I'm gonna select the debug. And I'm gonna choose ARM because I'm debugging to an ARM device. Raspberry Pi 2 has an ARM processor. Whoop. Finally I'm gonna select remote machine. It's hooked up to the network and I'm going to copy the IP address from before and deploy. So while this is deploying, the very first deployment to a Raspberry Pi takes a little bit, but it's a $30 computer so you can only expect so much. After the very first F5, whoops, it speeds up drastically. And you'll observe that in just a moment. So while this is deploying, I do wanna explain the logic of how this device is actually going to work. So if we go back to the PowerPoint, I can see this is kind of the overhead view of my device. So if I were looking at it like this, this is what I would be seeing. And I can see I've got my customer ready to enter the door, it's my Ninja Cat riding a T-Rex with a Microsoft flag. And I can see both of the Boolean values are gonna start at false. Meaning they have not crossed any of the sensors. So as soon as my customer enters through the first sensor, so they've gone halfway through the door, I change the value for my enter device. I know the value of this sensor has changed. I can respond to it and I can change the Boolean value that I'm tracking. As it continues through the door, I can now see both of those Boolean values have been set to true, or in this case, both of the sensors have been broken. And I know an entry event has occurred because entry sensor was fired off first and then exit sensor. Now if the reverse were true, if it went through the exit sensor first, and then the entry sensor, that's an exit event. Someone's walking out of my store. Just went like that and messed with you. So actually, if you look at the GitHub repository and someone goes like this and messes with you so that it messes it up, I actually have a timeout after a couple seconds if nothing happens, it resets the state of the device. Another example could be say a fly goes by and it messes it up. Yeah, so there are ways to counteract that and if you just know some simple C-sharp programming, it's pretty easy to do. But for the purposes of this, we don't have to worry about that case. So as soon as the event is triggered though, I'm gonna immediately reset the state of the device so that when the next customer comes through, it's ready to go. It needs to respond instantly. So let's see. So the application is almost done at fiving. Should take just a couple of seconds. It's kind of like using an emulator. It takes time to get the first time. First time, yeah. First time, right. Get everything over there, yeah. You're deploying to a device that's... And then this app along with .NET Runtime, the subset of it. And all likelihood that runs on this device, right? .NET's already on here at the Runtime. So you're copying the, what literally are you putting on there? Just the executable. So in this case, it's everything that comes with the application. So all of the references, all of my new packages. So it's interesting you mentioned the .NET Runtime. So with the Universal Windows platform, you can actually package your .NET Runtime as a part of your application. So since this is a debug application, it's not a store application. It's actually deploying .NET basically. Okay. However, if I were submitting an application to the store, for example, that shares the same exact .NET Runtime as all of the other apps in the store, obviously we're not gonna include that version of the .NET Runtime with every app. So there are shared frameworks that you can take advantage of. Okay. But you can actually change the version of the .NET libraries you wanna reference through NuGet. It's pretty cool. Cool. And then how much storage is on this device? How many apps like this can you get on there? It depends on your SD card. So I actually have a micro SD card on here. It's hard to see. But that actually has the operating system as well. So if I wanna flash this device with a new operating system, I can take out that micro SD card, plug it into my computer, download the latest preview build of IoT Core and plug it back in and it's ready to go. All right. Yep. Cool. Great. So the application is gone and it looks like a break point was already hit probably when I reached over. Yeah. So I triggered one of these sensors and we'll go into more detail. So you triggered the exit first because you reached through. I think so. I always get mixed up which one's entrance and which one's exit. So I might just have to turn it around. Oh, okay. I triggered one of them first. But what's interesting is I just need to know what is happening when that break point is hit. What are the values that I'm tracking at this point? So in this case I can see the value has changed from my exit sensor and I wanna track the arguments that are being passed into this event. So I can just use visual studio debugging tools to look at the local variables and see that args.edge is equal to falling edge. And I know that seems kind of cryptic almost but this is the parameter that you're gonna track with most of the digital devices that connect to these IoT devices. And if you did more of the tutorials that would become more obvious. But even if you don't do the tutorials you can figure it out just from some clever debugging. Right. So what that means is the instant that that break point was hit means the sensor is broken. Right. And when the sensor is broken args.edge is equal to GPIO pin edge dot falling edge. So that's how I track if it's broken. If it's unbroken it's gonna be equal to rising edge. Okay. And those are just enumeration values. So I can stop otherwise I'm gonna throw an exception and use that knowledge to finish my logic. So this is the important part. And then for reference the beam is broken. And now else the beam is unbroken. There are really only two states for this device. Zero or one effectively. So now I can write the logic for my application on here using those if statements. So as soon as the beam is broken that's when I wanna set the Boolean value to true. So since this is my exit sensor value equals value changed I need to set exit equal to true. Now if the enter sensor had already been fired that Boolean value would already be true. Meaning this one was fired second. That's when I know an event has happened. Right. So if enter now I'm gonna say customer has entered true. That means someone has entered my store. That method doesn't exist. We're gonna write it in just a moment. Okay. Else well exit is already equal to true. Otherwise I really don't need to do much. So in this case I actually wanna break out of my method and not do anything else. Did the backwards from how I normally do it. Normally I put exit equals true at the bottom but it shouldn't really matter. Okay. So the only other thing that I wanna do if enter is equal to true is reset the state of the device.  So I will reset both of those Boolean values to false. So now it's ready to go for the next person. So the code in customer has entered is what's going to send the message. Send the event to Azure. Correct. Okay. So now if the beam is unbroken I actually have a light to track when the beam is broken and unbroken for debugging purposes. That's all that's gonna happen here. So as soon as the beam is broken let's turn the light on. So exit light dot write GPIO pin value dot low. And if you do blinky that hello world of IoT devices that line of code should be pretty familiar. The light. So the LEDs here's a red and a yellow LED in the little bit of the device. So now I'm just gonna copy and paste that to here and I'm gonna write the value of high to turn it off. And that's really all I need to do for this. So I can just copy and paste this segment into the customer has entered method. Oops, sorry, no. The entry sensor value change method. And let's take a look here. So let me lower the output a little bit so we can see everything. So now if args.edge equals GPIO pin edge falling edge they're the same exact devices. This is the same exact behavior. This is right. The only thing that's gonna change is now I'm working with the entry sensor. Right. So enter light. Enter equals true. Entry light. Entry light. Now if exit, so if exit was already fired I'm actually gonna be sending an exit event. So exit was fired first and then enter. I'm still gonna reset the state of the device that is the same. Else entry light.write GPIO pin value of high. So the last thing I wanna do is remove the not implemented exception here and just place a break point to make sure that the events are working as proper or as we expect before we send a message to the Azure website let's make sure we're getting the right expected behavior. Right. So now you'll see deployment should be much faster this time. Deploy succeeded. That was much faster. Yes it was. There you go. So the break point is ready to go. So the first thing I'm gonna do is just cover one of these. Oops. Sometimes when you have some bright lights like a studio light it interferes with the sensors but if I cover this one pretty closely I can see the red light is turning on. The light's blinking. Right. So now if I cover this one, the yellow one I can see the lights actually staying on because a break point's it. So the code is not continuing to execute to turn the light off. Right. So here I can see in this case V is false. That is an exit event. So that is going out of the door. That means if I were to continue execution of the code and go the other way it should be true. So let's try it. Let's cover yellow first and then red. So again break point and now I see V is equal to true. Yep. Red stays on because again the code's not gonna turn the light off until it continues to execute. Right. So that's all I need to know. So my entry and exit events are working properly on the device. Now let's actually do something with that information. So again just using C sharp code I can create my object triggered event which I need to first add a reference to my portable class library models folder. Let's call it event T event equals U event. And I'm just gonna go ahead and create the event in line. So event time equals date time dot now event type equals V. I'm thinking I might actually, I have a theory that when I'm gone my cat just sleeps all day long. Now you'll be able to find out. Yeah that'd be cool. You could actually use proximity sensors instead of IR beam sensors. So instead of tripping a beam if it goes near it you could also trigger an event. Right so you can track things at the home you can use this as a security device or some type of monitoring. If you're one of those data obsessed people as well you can figure out where your cat spends the most time in the house. Just by all near the bed. I already know that. Put a sensor under the bed and you could actually calculate how much time spent under the bed versus other places. Lots of funny stuff you can do. So I've got my event now I just need to actually create the content to send to my HTTP web application. So HTTP content equals new string content. The string itself is just gonna be T event dot two string and then I'm actually gonna use some of the overloaded parameters to send the media type. So I'm interested in telling my ASP dot net application that this is JSON that I'm sending because of my T event two string method I overload it. I can actually navigate to it to return the JSON serialization of that object and that's so that it works properly with my ASP dot net app. So let me just do encoding dot utf eight and then application JSON. And one thing that I always accidentally do is do forward slash or back slash so I always get it confused so I can make sure I do it right. Application slash JSON, perfect. Cool, so the only thing I need to add now is I just have to post it. So this is the one I want. Content should actually give it a name. And now all I need to do is HTTP client which I already have, oops, sorry, client. I already have my HTTP client I don't need to recreate it, dot post async. The request URI is going to be API slash event and I'll show you where that comes from and then the actual content. So the API event is just what's appended to my base URI. So my base URI is shopanalyticservice.azurewebsites.net API event is what's at the end. So now if I were to do this. How does it know where did you specify the base URI? So I specified, yes, so I specified the base URI. Oops, I lost debugging to my live service. Sometimes it times out, so I'm gonna tap debugger again and you'll see why very soon. So up above is where I specified the client information. Base URI equals keys.azurewebsites.appAPURI. And then when I actually create the client in main page dot load, sorry, it's way at the bottom. Client equals near here. Client equals new HTTP client. So yeah, so as soon as this page loads, what I do is I create my HTTP client with that base address and then I initialize the board. Right, yep, cool, let's try attaching one more time. Sometimes you get finicky behavior with live running services. So anyways, let's go ahead and actually deploy this application to the device and set a break point when the customer has entered the store or exited depending on the perimeter pass through. And just so we can track the entire. This code's running on the device. This code is executing on the device. And you've set a break point and it's gonna show up in Visual Studio because you are debugging on the remote machine. I'm doing remote machine debugging on the IoT device. That is cool. Yeah, so remote machine debugging has existed for a long time. You could do PC to PC. But now I can do PC to Xbox, PC to IoT, PC to Surface Hub, Xbox, you name it. Let's see what's going on with this one. My live services not behaving so well, but that's okay. We'll go ahead, let's see a break point. Perfect, this should be true. Someone has, should be coming into the door. So on my local variables load V equals true. I can hit F5 again. And now what I should see is as soon as it sends the event, it has executed properly. I should get a push notification. That's where I was saying my live service. Oh, there we go. So a little bit delayed, but someone has entered the store. So a couple of seconds later. Now what's interesting is I can actually view all of the events that I sent so far again in Visual Studio. So if I go to document DB accounts, in Cloud Explorer. And you're using that because it's just unstructured data and no need to spin up a whole database. So this is, I'm actually using, yeah, it's just a list. So I'm using document DB, which is a NoSQL database. All it is is a JSON document. For the demo, I just have a single document, but one of the things we're working on in the repository is making it more scalable to use the NoSQL querying that is supported. So creating a new document for every event and then a collection for every month, for example, and then we could kind of parse it however we want. But you'll see why I use a single document when I copy and paste all my fake data and it's really convenient. So if I find my document, see, document DB is very powerful, but I just have my single document. I can go ahead and load. And here we go. So at the very beginning we did 20 o'clock, eight o'clock global standard time, and I said true. And then I've done one real event that I sent through the IoT device, which happened just a couple, about a minute ago, which is 144 and it's now 145. So that is the real event. And I didn't have to leave Visual Studio at all for that. So now, just for convenience, I wanna show you another tool that you can use for document DB to copy and paste the data so you can actually see the data when I run the next app. So in the Azure portal, I can again go ahead and refresh this document. This is the live document. Here are the two events that I was just working with. Now let me go ahead and find my fake data. I have a lot more than just that. And this will actually make the app look like something. There we go. Many more events. So I can go ahead and save that. And now my database has been updated with that data. So makes it really easy to test it. It's better than going like this. It's better than going like this. It's 1500 times. Exactly. Although you get lots of steps on the band. My arm will get really tired though. So I'm actually gonna break out of Visual Studio 2015 for now. But first I wanna deploy the IoT device. So I'm not gonna debug it. I'm just gonna hit control F5 to deploy it without debugging. And then it'll just continue to run on that IoT device for pretty much ever. So I think one funny example is I went on vacation and deployed it before vacation. Came back a little over a week later. It was still running fine. I came back and swung my hand across saw the lights, saw the push notification. Cool. It's pretty reliable. No crashes or anything like that. So deploy has succeeded. I can go ahead and close this instance of Visual Studio. Let me go ahead and get rid of this instance of Visual Studio. I don't know why that debugging wasn't working. That's okay. And let's take a look at Visual Studio 15 preview. Which preview version is this? So this is the next major release of Visual Studio. Visual Studio 15 preview four is available today. This is four. This is actually beyond four. Oh, okay. So this is latest and greatest. You never know what could happen. Hopefully everything works properly. So four is available publicly and this is something past that. Yes, this is something past what is available publicly. This is one of the beauties of working at Microsoft is getting to play with daily bits of everything. It's awesome. So let's go ahead and take a look at this application. This is what's going to visualize the data. I really just have one page that I'm doing. There's a lot of code that processes the data behind the scenes and that's where, again, we can optimize our database structure to just do that in the cloud using querying. But for now, we're not going to worry too much about it. Oh, here you go. We might have some IntelliSense bugs with this version of Visual Studio, but I don't think we need it. We're not actually going to write too much XAML. But the designer works, so that's good. So let's take a look at the designer first to see what this looks like. So on a phone, I can see I have a grid here, and it's a little easier to view the structure on a desktop first because of adaptive code. So if I zoom in, I can see I effectively have a grid within a grid. So here's my main grid, is the outer entire rectangle is the first main grid, and in that grid I have two rows. This is the first row, and then this entire thing is the second row. So the first row just contains my coffee shop name, the hours that I'm open. It'll also give me information about when the data was refreshed. Then in here, I have this picture that tells me how many people are currently in my store. If it's really busy and people are lining up to the door or something, I want to know how busy it is. And then I have three graphs that'll be displayed in quadrants. And what I do is I actually write this adaptively so that if it were on a phone, I would just be able to scroll through each of those charts. So I can see here's one of the charts below, and then it's not going to show you the rest because it's cut out of the UI, but I could scroll through it and I'll demonstrate that as well. So I'm going to go ahead and just deploy this application. And what I want to show here is one of the new features that's coming out in Visual Studio 15 for XAML development. To really help you build performant XAML apps. Okay, so this should take just a second. I'll also show you a couple of tools that have been out for a little while now, but a lot of people still don't know all about them. They've only been out for a little over a year. So this application is running. So let me close some of this. So what I want to show you first is what is new. So inside of the diagnostics tools window, we have these diagnostics while debugging tools that run just while you have Fiber app. There's a new one called UI analysis for UWP tools. Now this is not on by default since it's brand new. So for those of you watching, if you want to turn this on, all you have to do is click select tools, check on UI analysis, and then you'll have to reset the debugging session. Okay. It's pretty painless. But what that does is it gives me a whole bunch of different events about my application and the performance of my application. So the number one is using binding instead of compiled bindings. I'll have to go ahead and fix that at some point. But the one that I want to show you is one that actually surprised me. And I found out about this because of this tool. So let me restart my application. Here's the app, you can see all the data. Let me restart my application and describe what I'm doing that is bad that UI analysis told me about that I had no clue about. It's actually pretty cool. So when my application first launches, I can see I don't see much except for this loading ring. And what I'm actually doing behind the scenes is I'm creating these objects and I'm just hiding them. So I'm setting their visibility property to visibility.collapse. And what that means is on startup, it's still loading that XAML control into memory, it's having to do the processing to create it and just not doing anything with it. And what UI analysis told me is, let me find one of them. Here we go. Element num people in store of type 1RTE, it's the charting control was collapsed at load time. So it told me that collapsing an element or setting its opacity to zero will not prevent the element from being created. So it is creating the element, it's using processing power, it's slowing down my startup time. Well, that's something I definitely want to fix. So not only that, but I can actually, this is gonna work, it might be broken because of this. It's the problem with daily builds. So when this is out, if I double click on this, it'll take me to the line in XAML that is causing that to break. So I can actually just go ahead and navigate to it. So num people in store right here. So here's the chart. So now what I want to do is change one of the properties. So it's gonna be hard without IntelliSense, but I can do it. So X colon deferload strategy is the way to fix this. Oh, I do have IntelliSense, lazy. Cool, just I don't have the highlighting I guess. So I'm gonna set a property called X colon deferload strategy equals lazy on this chart. And then I have to do one other thing. So I have to navigate to it in the code behind. One other tool that I always do this myself, I've just gotten so used to it. XAML edit and continue is another new tool in Visual Studio 15. As you'll notice, this application is still running. I'm still debugging this app. And I just added that property to my XAML without having to stop anything. And I just did that because I'm used to it now. So I think that's really gonna transform the way people create XAML applications. So I will stop it because now I'm gonna have to edit the code behind. Let's go ahead and here. And let me make sure I get the right property name. So X num people in store. So the way I'm gonna get rid of that warning in UI analysis is I'm gonna set that property and then I'm gonna call it somewhere in the code where it actually makes sense to finally load that element. So it's not gonna be read at startup. It's gonna be when I have the data available to actually make that chart meaningful. So I'm gonna look at my code and I can see on main page loaded, I get the data and then I set the data context. And as you can see, I already did it for a different control before. But if I do this dot find name, num people in store, this doesn't actually do anything, but it tells the code, hey, I need to create this object. I'm trying to do something with this object. So it'll create it in UI. So this is gonna retrieve the object that has a specified identifier name. So in trying to retrieve it, it's telling the XAML, hey, you need to create it. So now if I run this again, I should only see five, I guess infractions of that specific UI analysis type. So here we go. So now if I go back here and I select filter UI analysis, it's down to 48 instead of 49, visibility collapsed. So as you're debugging, what's amazing about this is since it's while you're debugging, you'll catch these as you write your code. So rather than waiting until the very end of doing your post-mortem profiling, your app file ready to go, oh wait, you have 60 performance things to fix on your UI threads. Well now as you hit these issues, you just go ahead and fix them. It's pretty quick, yeah. So the last thing I wanna show is UI debugging, XAML UI debugging. That has- Can you get those before running? Is there a? No, so those are actually calculated at runtime. So there's a process running that will tell you that this issue is occurring. Okay. So the last thing I'm gonna demo is actually in Visual Studio 2015 with this same application. And I wanna show it, because not many people know about it. Hardcore XAML developers definitely know about it now, but there's still a lot of new developers that are not aware of this feature. And I wanna make sure it's pretty evident to them that they have this tool box available to them. So XAML UI debugging is kind of the precursor to XAML Edit and Continue, which I showed you before. And I think it might be a little busted in Visual Studio 15, but that's what happens when you play with today's build. So let's go ahead and hit F5. It should still work. I've seen that warning before. It's because I forgot to add a reference to my portable class library, but the binary output of this folder is enough to get it to work because in another project I have the reference, it's confusing. But yeah, the app works. I just wanna show this XAML UI debugging. So live visual tree now, I can see it. So here I've got this actual adorner in my running application. Let me go ahead and actually, while this is running, let me show you the adaptive UI nature. So if I make this really skinny, after a certain point, it makes everything in a single column and I can just scroll down. So the behavior on the phone is I just go ahead and swipe and I can see everything working. But now, let's say I wanted to change some of the styling on this. Say I don't like the size of Contoso Coffee Shop. I can go ahead and click on the adorner. Is that always been collapsible like that? Since update three, yeah. Oh, cool. I knew it showed up. So you can also hide it. But I didn't know it was collapsible. This one as well. So you can get rid of it entirely if it's interfering with your app. So on the topic of getting rid of things, go back there. Why is this? This should be in tools options as a global setting. A framework. I never ever want it. I never ever want it unless I explicitly turn it on and I shouldn't have to go into app.demo.cs for every single one and get rid of it. Yes? Sure. That's good for you. We've actually had this feedback before. There's two sides of the fence. There's the people who actually do use this information. Fine. That's why tools options, you said it globally. All right. I'll take that back to my team. All right. Thanks for that feedback. It's a great feature. When I'm building an application, Just get in the way. I don't even know if the thing works yet. I'm, frame rate is one of the last things I'm gonna check. That's true. Never the first thing. Yep. Okay. But you can see, kind of. See, that's one of the benefits of having a show and inviting folks from the product team. There you go. It's a prior wisdom. So what XAML UI debugging does is it lets me select that control and then when that control is selected, in my effectively, this is kind of like the DOM for those of you who do web debugging, I can see all of my visual elements that are at runtime. And this could be programmatically generated controls. If it has this next to it, it means it was user generated in a page. Okay. So I can actually click that to navigate to the control in the XAML. So let me actually just show the XAML. So that's the text block that I'm actually looking at here. So this version of Visual Studio does not support XAML edit and continue, but the power of that is, I can use XAML UI debugging to find the control. Right. Then I can use the live property explorer to modify local properties of it. So I can set that to 30 to make it bigger. I think that looks a little bit better. And now if I were to stop this application and run it again, it would revert back to 24. Right. But with XAML edit and continue, I can then after testing in the live property explorer, I could then edit the XAML file while it's debugging, change the values of the property, hit save, and then just keep going. And I don't even need to stop the application. So. That is cool. Yeah, it's pretty powerful. It's one of my favorite new features in Visual Studio 15. Oops. Don't know what I did there. I accidentally hit alt tab. I wanted to go back to this one. Oh, it's still going. But yeah, those are some of the new tools. Cool. Any questions? Yeah, one question. So the Raspberry Pi sends a message to the Azure service. Yep. Which then use notification hub to send a message out to the client. Right? Yes. Okay, so someone, an event driven model where an event is fired and the Azure service kind of wakes up. That sounds like what Azure functions are. So did you consider using Azure functions for the server side stuff? So I initially didn't consider using Azure functions mostly because I wanted to demonstrate the power of sharing.net code across all of these different platforms. So I'm using UWP. I'm using ASP.net, and I'm using the same code for all of them. Yep. But Azure functions would also serve the purpose of what I'm doing. Okay, cool. Yep, but just to show this one last time as I'm running this, it should trigger an event and I should see current people in store either increment or decrement. I don't, decrement, that was exiting. So now I have quite a few people in the store. So if I go this way, then it should go back to zero. Cool. And it's pretty fast, so ready? Oops, it might have missed. Oh yeah, there you go, one. So takes two seconds, three seconds. Cool. Get a notification and update it. So you could have that, you could have a screen like this in the window of the store shows the number of people in the store and what the average wait time would be. I could do that too. Yeah, so I could hook this up to my register. So one of the things I was considering just additional functionality is having register functionality in this app. And then I could do how quickly our orders processed, how much is the average order. I could show, correlate this data with money instead of just how many people are in the store if I'm running a promotion. Maybe I'm giving discounts, so more people might not equal more money, et cetera. But the last thing I did wanna show is a couple of resources for this. Mostly the GitHub page, I think that's what's gonna be. So all the code is up in GitHub for both the client and the server. Yep, and if you have any issues with it or any questions, raise an issue or tweet me at PMM Mike. This is gonna be a living repository for a while. Cool. Makes a good sample of all the different services available to you. And did they open the coffee store? Are they using this? Are they using it today? No, so this is still just V1. We have to first create our printed circuit board and put it in, no, not yet. Okay. Maybe someday. Thanks so much. All right, cool. This is a great example. Thanks for coming on and showing. Not a problem. Yeah, it's a lot of fun. All right, hope you enjoyed that. Take a look at the code, play around with it, let us know what you think and we'll see you next time on Visual Studio Toolbox.


Man, Toyota and Prestonsburg is offering 0.9 percent financing on the 2018 Camry. The Toyota Camry offers performance and safety with breakthrough design and sporty styling. At Man, Toyota, it's affordable. Man, what a deal.  Tuesday, a federal judge sentenced 40-year-old Scott Dwayne Tackett of Melvin to 66 months in prison. Back in August, Tackett admitted to conspiring to sell pills with his girlfriend, Alyssa K. Isaac, and her parents, Jeffrey and Karen Elizabeth Isaac, all of Melvin in June and July of 2016. During the investigation, nearly 4,000 pills were confiscated. A Mingo County woman will spend six years in prison after pleading guilty to child sex trafficking. 40-year-old Misty Dawn Basedon of Del Barton appeared in U.S. District Court in Charleston Tuesday to learn her fate.   With your EKB-TV News Brief, I'm Shelby Porter.