- [Instructor] We're over in Visual Studio 2017 in our Tagger app, to take a look at getting our Universal Windows platform app Tagger, that we've been working on in this series ready for network connectivity. Just as a review, let's run the app as a reminder for where we're at in this series. We've already gone through layout navigation concepts using basic and advanced controls and even creating custom controls, and essentially, we're at the point that we've got a nice working navigation system. We've got images that load up. They're captioned if they're videos.
We can play the videos. What I thought we could do, just as a demonstration, is to take this page, this Groups page, page one. Let's just add a web view control to create a little web browser in that page. We'll just open up page one. Let's just get rid of that text block that's in there. Let's just add a web view. We'll make the source one of my favorite locations. We'll go to dev.windows.com.
Now, let's just run the app and navigate to that page. Notice how we aren't seeing any web content. It's actually not navigating to dev.windows.com. This is usually an indicator that we don't have network connectivity, and in this case, internet access in our apps. Our device might have internet access, but our Tagger app does not. Here's were we manage explicit permissions for network capability, including internet.
Go ahead and open that app manifest and go to capabilities. You'll notice in this capabilities list we have this long list of capabilities. About five or six of them have to do with network connectivity. By default we need to have either internet client or internet client and server capability declared, in order to access internet resources. Internet client server is really a super set of the internet client. Internet client essentially means we can download content. Internet client server means we can go both directions.
There are some variations in that, but let's select internet client and server, and just to make sure we're aware of what happens if we go back and view that manifest directly. It's out of the capability in the capability section of our app manifest, internet client server. Let's go ahead and run our app. If we navigate to that page, there we go. We've got the content from dev.windows.com loaded up.
We can just navigate through this all day long. No problem here. An important concept here is this is just a web browser, but this is going to effect every bit of internet communication that we're going to have from this app. So, we could not call anything over HTTP protocol for example. We might be able to connect to other resources like local or domain resources, but we couldn't actually use our internet connection in any way. Okay, so that's great. Let's go back over to our manifest.
Just take a look at some of the other capabilities that are available. You only need internet or internet client. If you have internet client and server you don't need internet client. You can select them both if you want. One that we're not going to look at immediately, but that's important, is enterprise authentication. This is a special capability that actually will require store authorization, if you want to enable this capability. Enterprise authentication is going to be critical when you're talking about credential hops across domain resources.
It's extremely common in a company app in an organization or enterprise level app, one that you might upload to the business store to need enterprise authentication. This says that maybe I'll have domain credentials, for example, and we want those credentials and that credential hop to be able to pass through and access domain specific resources. This is actually disabled by default and we have to explicitly state that we want enterprise authentication for that. A couple more that are really helpful are Bluetooth and proximity.
Bluetooth of course gives us access to Bluetooth devices. One example that I use all the time is for Microsoft Band or other devices like that, other wearables or four Bluetooth resources like speakers for headphones. We could easily access those resources if we enable Bluetooth capability. Proximity is something that's really great that's actually fairly underused. Proximity is for things like NFC, near field communication. If we just wanted to do tap and sends or things like that, we might need proximity.
Another one that kind of challenges developer at times is this private networks, client and server. They think that maybe just 'cause they have enterprise authentication or internet access, that they can access content over VPN for example. Well, this won't be true unless they select private networks as well. Now that we've got the internet connectivity this will give us the ability to do web browsing. This will give us the ability to make any type of HTTP request we want, for example, against a web service or a REST service or any other resources that require HTTP or HTTPS.
One other thing that I think is helpful in the Universal Windows platform is the ability to access network resources and understand changes to network connectivity. This is extremely helpful, for example, if you're on a mobile device and you want to know, hey, if the device doesn't have connectivity, or if it has restricted capabilities, for example, if the connection is governed some way or there's some issues with the data plan or we want to check the speed, see if they're actually on a NIC or a NIC card, or if they're on wireless. The Universal Windows platform has robust features to listen for network changes as well as analyze network access and the level of network access.
What we're going to go ahead and do is, in our start view model just add a listener for network connectivity changes. If I were to add this when my app starts up, we're basically taking the networking connectivity, network information object and we're going to listen for a network status changed event, and were going to call that On Network Status Changed. We'll go down here and we'll drag this On Network Changed event in here.
Let's take a look at what's happening. Essentially any time your app senses a change in the network. This could be that your network cord gets plugged in or unplugged, or you go into airplane mode, or a WiFi connection changes, or you lose connectivity. This On Network Status Changed event is now going to be triggered. As we're working in the Universal Windows platform we always have the ability to grab the internet connection profile from the network information, and pull that information back. What we're going to do here is, when the network status changes, we're going to take a look at that profile, and if that profile has at least constrained internet access.
This says that we've got access, but we might have some constraints against it. For example, maybe we're on a mobile device. If we have at least constrained access, we're going to consider that we're connected. If we don't have it, if it's less than constrained access, we're going to say that this is disconnected. Just so that we clarify, let's look at these enumerations. We've really got constrained internet access, internet access, local access, or none. Now, local access would, for all intents and purposes, say that you don't have connectivity, because local access is just saying, hey, I can connect to my box or sometimes some network resources, and then of course none means I have none.
For most apps you're going to have internet access, but you could have constrained internet access, which means you need to pay attention to the resources that you're passing back and forth. We're going to take a look at that profile. We're going to decide whether it's connected or disconnected. I'm going to set this value. This boolean value is disconnected, the true or false, any time there's a network status change. The idea was that we could throw this into our UI, so that we can make users aware of whether they have network connectivity or not.
Let's go over to our start page. You'll recall that we have this nice border up top where we've got this hamburger navigation. I thought it might be nice just to throw a label in here. Now, in the real world, you might want to have this label show in different locations depending on the device. For example the standard in a desktop app is to have this label up top. In a mobile app or small form factor, you're supposed to have it at the bottom. There's variations for that for Xbox and other scenarios. But, just for demonstration purposes, we're just going to throw a label up in here.
That's going to notify a user when he no longer has internet connectivity. Let me just go ahead and drag that in. We can take a look at that and see, this is just a text block. The label's going to say, "No Connection," and it's only going to be visible if it's disconnected. We're going to use that boolean to visibility converter and only show if it's connected. Let's go ahead and load that up.
We'll see that it does not show that we're disconnected, that we have internet connection, but let me go ahead and disconnect my network cable from my NIC card. Notice how we get a break point now in our On Network Status Changed that says that our current network connectivity level, in fact we'll just look at that down here in the Immediate pane is internet access, and so then we're thinking, "Well, what's happening here? "Why do I still have internet access "if I connected my network cable?" Well, we still have wireless connected.
Let's go ahead and move that to airplane mode. Notice that my connectivity level is now local access. Notice that my UI says, "No connection." That's pretty cool, this gives us the ability to respond to events based on network connectivity in a very robust way, so for example, if we're in the middle of a data transfer or were trying to point content, we can immediately fail over to other scenarios, and even chain or nest these scenarios based on our connectivity. We might want to for example, pause some kind of a process and wait for the connection to come back online, or maybe we're in the process of synchronizing data.
We may want to pause that data, and then when we sense automatically that that connection has back online, we can just resume that process. You'll see that the line of code that it takes to do this is extremely simple, in fact I could have actually made this about one line of code. I could have just simply queried the network connectivity level to drive this information. So, that's pretty cool. Let's flip back over to the slide deck and talk about now that we have our app ready for network access, how we could extend this capability by accessing for example, some web services and web API resources
Note: This course was created by Wintellect. We are pleased to host this training in our library.