Mobile apps that work offline as well as online present an interesting set of challenges. Use immutable data structures, historical models, MVVM, and pub/sub to build apps that help people work and play together.
Rich, compelling mobile applications bring users closer to their data. They respond quickly, even if the network connection is slow or unavailable. They help users to collaborate with one another: a change made on one device by one user is automatically visible on other devices. And when something goes wrong, they help the user recognize the problem and correct it. Your users expect more from their mobile apps; build one that they will love.
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).
History Welcome back to Occasionally Connected Windows Mobile Apps: Collaboration. I'm Michael L. Perry. Now that we know how the theory of immutability is going to help us to build more responsive collaborative applications, let's go ahead and apply that. We'll start by capturing a history, and then applying those historical facts to an object model. We'll be building the Card Board application that I demonstrated at the beginning of this course, and here's an overview of the components that make up that application. In this module, we'll design a Historical Model and an Object Model, and then the set of messages that apply those historical facts to that object model. And then in module three, we'll project that object model through a view model and data-bind it to the view. And then in module four, we'll persist those messages into a message store and a message queue. This will help us to show the user the most recent persisted state and to capture their intent to share with other users. And then in module five, we'll wrap it up with a distributor, which will take those messages from the message queue and send them out to other users of the app. So let's kick it off with the historical model, the object model, and the set of messages.
Projection Welcome back to Occasionally Connected Mobile Apps: Collaboration. I'm Michael L. Perry. Now that we have our models, let's go ahead and create projections. This is how we're going to query history in order to find the current state. We'll project that history as captured in the object model onto a view model, so that we can data bind it to a view. In this module, I'm just going to focus on those patterns that are particular to occasionally connected mobile apps. But for a complete list of patterns, please see my previous course, Clean View Models With Assisticant. We will be using the Assisticant open source library to do all of our data binding.
Persistence Welcome back to Occasionally Connected Windows Mobile Apps: Collaboration. I'm Michael L. Perry. We're building a collaborative mobile application based on the idea of immutable messages representing historical facts. Now we're going to persist those messages so that we can rehydrate application state and then send those messages to users using other devices. We'll do that with two persistent data structures, a Message Store, and a Message Queue. The message store will save all of the messages necessary to rehydrate each of the objects in the application. And the message queue will save all the objects that haven't yet been sent to the distributor. Let's take a look at the patterns that we'll use to build them.
Distribution Welcome back to Occasionally Connected Windows Mobile Apps: Collaboration. This is module five, Distribution. This module will give you all the patterns that you need in order to send messages across devices. This is the final piece of our application architecture. And if you recall, we've done some work ahead of time in order to relax the requirements placed upon our distribution subsystem. We made sure that our messages were idempotent. That means that if I apply a message twice, I'll get the same effect as if I applied it once. Idempotency will allow us to tolerate duplication, which means we don't have to build in anti-duplication mechanisms into our distribution subsystem. We also made sure that our messages had a partial order, and not a total order. This is what allows us to apply a message to a local device before we've even sent it to the distributor. Devices of collaborators will get the message as quickly as possible, but they'll still apply it in a different order than the originator. And finally, we made sure to include the predecessors within a message whenever the order was important. This is going to allow us to relax the delivery order of messages from the distributor, so we can use things like push notifications in order to send messages to a client. Push notifications will enable real-time collaboration, but they're not guaranteed delivery, and so they could arrive out of order or not at all. Let's take a look at all the patterns that we're going to use in order to build our distribution subsystem.