Nowadays, an app's capability to work online and offline is essential to users. This course, Occasionally Connected Windows Mobile Apps: Consumer, will teach you how to design an app that caches data while offline and keeps track of the consumer's actions. You'll also learn how to send that data to the server without user intervention when they reconnect. You'll discover how to give the server the agency to act on the user's behalf, as well as use that data to provide a continuous experience across devices. Finally, you'll be able to put all of these patterns into practice in a Universal Windows App that will get 5-star reviews. By the end of this course, you'll be able to design great apps that operate perfectly whether they're online or not.
Mathematician and software developer, Michael L Perry applies formal proof to creating reliable software. He has developed a method starting from the works of the greats (Meyer, Rumbaugh, Knuth), and embodied it in his open-source frameworks (Update Controls and Correspondence).
Course Overview Hello there, my name is Michael L. Perry, and welcome to this course, Occasionally Connected Windows Mobile Apps: Consumer. I'm a principal consultant at Improving and a Microsoft MVP in Windows Platform Development. We have some great tools for developing mobile applications for the Windows platform, but we still have some challenges, not the least of which is the fact that the network connection on a mobile device is unreliable. This course will teach you how to build compelling consumer mobile applications that work just as well offline as they do while they're online. These apps will persist the information that the user has already seen, and then retain whatever action they've taken upon that information until they have a good network connection. They'll make intelligent decisions on the user's behalf, and they'll continue the excellent experience from one device to the next. Along the way, we'll study patterns for caching, event sourcing, historical modeling, and security, just to name a few, and by the end we will have built a complete consumer experience, soup to nuts. So warm up Visual Studio and the Windows Phone Emulator, and let's get started building an occasionally connected Windows mobile app for consumers on Pluralsight.
Designing Compelling Consumer Experiences Hello, and welcome to Occasionally Connected Windows Mobile Apps: Consumer. I'm Michael L. Perry, and I'm going to be teaching you how to design and build compelling consumer experiences that are not always connected to the Internet. This is the third in a series of courses, the first focusing on collaboration, and the second on enterprise line of business. I suggest you at least watch the first of these courses before starting this one. The objectives of this course are first to learn what makes a compelling consumer experience. We're going to take a look at the properties of such a compelling experience, and then we'll see some counter examples, some applications that don't have these properties. Good design is invisible, so it's easier to see these properties when they're absent. And third, we'll actually design a compelling consumer experience that has all of these properties. That'll take us through the first module, but then in the remaining modules we'll learn how to achieve the compelling consumer experience that we've designed. In module two, we'll focus on isolating the mobile application from third-party services. Module three, we'll tackle caching data on the mobile device. Then we'll look at the separation of responsibilities between the mobile app and the server. And then finally, we'll wrap it up by implementing continuity where we have a continuous experience from one device to the next. So let's get right into the properties of a compelling consumer experience.
Isolating Mobile Clients from Data Services Welcome back to Occasionally Connected Mobile Apps: Consumer. In this module, we're talking about Isolating Mobile Clients from Data Services. In the last module, we discussed why it's important to isolate mobile clients, but in this module we're going to dive a bit deeper. We'll talk about the typical topologies of mobile applications that use third-party data services, and those will include connecting directly from the device to the API and passing through a backend in order to get to the API. We'll see the problems that arise in these typical topologies in the form of availability, security, resilience, and efficiency. And then we'll take a look at the topology of a truly isolated service and go ahead and write this up in code. Let's kick things off by taking a look at an application that connects directly from the device to a third-party API.
Updating an Offline Mobile Cache Hello, this is Michael L. Perry. Welcome back to Occasionally Connected Windows Mobile Apps: Consumer. This is module three, Updating an Offline Mobile Cache. We've seen so far the advantages of isolating our mobile application from third-party data services, but now we're going to cache data offline in order to persist that data so that we show the user things that they've already seen. In this module, we'll take a look at two different cache management strategies. The first of those is offline mode, and this strategy makes people sad. The second one is offline first, and this one makes people happy. I'll demonstrate the problems that can occur with the offline mode pattern, and then I'll show you how to switch that into an offline first pattern. And then we'll take look at how to manage artwork. I'll show you the default operating system behavior first, but then we'll take control, and we'll manage the artwork caches ourselves. We're going to fetch the artwork asynchronously, and we're going to display what we've got in cache while we're offline. Throughout, we're going to exercise a caching strategy that involves displaying local data first. While the user is looking at that local data, we'll fetch updates asynchronously. When those updates finish coming down, we'll update our local cache, and then we'll update the user interface to show the user that we've got fresh data. There's one general rule that we're following throughout all of this. Never Data-Bind to the Internet. The Internet is slow and unreliable, especially on a mobile device, and so you want to data-bind to local data, and then refresh that in the background with your internet connection. Let me show you what I'm talking about by going over the offline mode pattern.
Separating Client and Server Responsibilities Welcome back to Occasionally Connected Windows Mobile Apps: Consumer. I'm your host, Michael L. Perry, and in this module we're talking about separating the client and server responsibilities. The reason for the separation is two-fold. First, we want to retain information on the client side until it connects to the server, but second we want the application to have agency. We want it to act on the user's behalf. And so to that end, this module is going to have three objectives. The first is identity. We need the client and the server to work together, so the server needs to know who the client is. Since this is a consumer app, we'll be using the Microsoft Live Identity Provider. For the mobile app to connect to Live ID, we'll be using the Web Authentication Broker. This will bring up a web page within the application, and then send the user's credentials to Microsoft, and then return an access to confirm Microsoft back to the mobile client. Once identity is taken care of, we'll focus on retention. The idea of retention is that we want to save user actions on the device while the device is disconnected. We will later send those actions to the server when a connection is available. Our third objective is going to be to give the application agency. This means that rather than having the user make all of the decisions, the application is going to do some work on the user's behalf. To do this, we'll store user actions in a central database on the backend. Now the backend agent has enough information to do what it needs to do, and so we'll start a WebJob in order to act on the user's behalf. This WebJob will search the central database for items needing its attention, and once it finds them, it will act upon them and then push messages back to the user's device. That's a lot to cover, so let's go ahead and get started with identity.