Mobile apps that are still functional while offline present a challenge. But when those apps represent the business of an enterprise, the challenges multiply. Build upon the patterns that we learned for creating collaborative occasionally-connected mobile apps for Windows, and extend them to integrate with a back end database. Represent the complex state-transitions and workflows of a business system. Identify security boundaries and federate authentication to Active Directory. When you are finished with this course, you will have all the tools you need to build a robust business application that works as well offline as it does online.
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).
Historical Modeling - Hello, this is Michael L. Perry. Welcome to Occasionally Connected Windows Mobile Apps: Enterprise Line of Business. I'm really excited about this course because it gives you all the tools that you need in order to build mobile apps that are useful for doing real work. These mobile apps will work just as well while they're offline as while they're online. The queue of the users changes so that they can exchange that information with other app users and with the back-end database. We'll kick things off with historical modeling and that's a way of modeling application state as the relationships among partially ordered facts. This skill is going to be crucial for a number of reasons, not the least of which is keeping mobile devices in sync. It's really hard to synchronize an object model or a relational model but a historical model is quite easy to synchronize. Now this course builds upon my previous one, Occasionally Connected Windows Mobile Apps: Collaboration. If you haven't watched it yet, you're going to want to go back and watch it now because that gives you all the patterns that you're going to need in order to build the app. But don't worry too much about all the code that we build inside of that course because I've taken the reusable parts of it and turned it into an open source project. That's the Rover Mobile app toolkit which you can find at rovermob. net. Now this course isn't intended as a tutorial on that open source library. I've just simply open sourced it so that you can follow along more easily. What we're going to be doing in this course is building a field service application. We're going to build that application on top of Rover Mobile so that we don't have to repeat all the lessons from the previous course.
States and Transitions - Hello, and thank you again for joining me. This is Michael L. Perry and you are watching occasionally connected Windows mobile apps, enterprise line of business. We've covered the patterns that you're going to need inside the mobile app itself in order to keep track of objects with their successors and their predecessors, but now we're going to transition over to the server side where we need to keep track of states and transitions. Let's say that we need to keep track of the state of an incident. An incident can be in any one of these states. It can be reported, meaning that somebody has reported that there's an incident at their home, and then it can be scheduled, which means that we have a technician scheduled to visit that home. The incident could also be awaiting parts if we've ordered some parts but haven't received them yet, or it could be awaiting a follow up, if, perhaps, we've already visited, but now we need to go back, say, to install some parts that we've ordered. And finally, the incident could be closed, in which case we don't need to act upon it anymore. So these are the various states that an incident can be in at any given time. And you see on these transitions between those states the various messages or facts that have occurred in order to get us from one state to the next. In this module we're going to be responding to those messages in order to transition the incident from one state to the next, and then we'll be able to query all of the incidents that are in a given state. This is something that's really much more important to know on the server side, and so we'll be doing all of this in SQL. So let's take a deeper dive into our various states and see how we're going to query the system.
Publish and Subscribe - Welcome back to Occasionally Connected Windows Mobile Apps: Enterprise and Line of Business. I'm Michael L. Perry, and this is Module 4, Publish and Subscribe. We saw in the previous course, Occasionally Connected Windows Mobile Apps: Collaboration, that messages are published and subscribed to topics. A Topic defines a common subset of facts that several different collaborators are interested in. In this module, we're going to go into a bit more detail on Topics, and see how they work with an Enterprise Line of Business application. First, we'll identify the Topics within our field service application. Next, we'll identify the Actors within the application, and see how they're going to subscribe to Topics in order to get the subset of information that they're interested in. Different Actors are going to coordinate with one another in order to collaborate on what Topics they're interested in. And then third, we'll see that Topics are actually the boundaries of Security within our application. To that end, we'll implement Authentication and Authorization in a way that's compatible with Enterprise Line of Business applications. This will give certain Actors the ability to post messages to a Topic and certain other Actors the ability to get messages from a Topic. So, let's dive right in, and identify the Topics within our field service application.
Enterprise Integration - Welcome back to occasionally connected Windows Mobile apps Enterprise line of business. We've seen everything that we need in order to build an incredibly rich, occasionally connected mobile application. But now, let's look at the patterns that are necessary in order to integrate it with an enterprise line of business back end. Our back end application is going to be running with an on-premises Database. The mobile app, however, is using a Cloud-hosted Distributor. The integration point is going to be a Bridge that turns all of the changes in the Database into messages that can be sent to the Distributor. And then, to go the other direction, messages from the Distributor are going to be transformed through this Bridge into stored procedure calls in the Database. In order to translate between the Database objects and the messages, we're going to need to set up a Message ID Map. And we're going to have to make some changes to the Distributor, including security, technician ID lookup, and publishing through Azure service bus. So, let's first talk about the overall architecture of this integration and then, we'll dive into the code.