The Parse mobile backend as a service makes it easy to build and manage mobile apps. It stores your user's data, gives you query capabilities, and lets them securely share with collaborators. We'll build a feature rich Windows 8 application on this platform. You'll learn patterns for connecting related objects, querying through relations, and remaining functional while offline.
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).
Introduction Just a couple of years ago, building mobile applications was a chore, but now with services like Parse it's much easier. Hello, I'm Michael L Perry. Thank you for spending a few hours with me to explore the Parse Mobile Backend as a service with Windows 8. During this course we're going to immerse ourselves in the Parse API for Windows by building a fully-featured mobile application. All of the data and user account management will be hosted in the Parse Cloud. We'll share data among users, alert them with push notifications, and even support going offline. As we explore, you'll pick up patterns that you can apply to your own applications. We'll use MVVM to structure our code. We'll use Linq to query related objects, and we'll queue changes made offline in order to apply them when the connection is restored. We'll put all of these patterns into practice on top of the Parse platform, online at parse. com. One of the richest mobile backends available right now, Parse was founded in 2011 by Ilya Sukhar, James Yu, and Kevin Lacker to simplify iOS and Android application development. They quickly expanded their services in APIs and now support Windows Phone and Windows 8. They were acquired by Facebook in 2013, but continue to innovate like a startup. They offer free service for up to 1 million requests per month, so you can build and deploy even a modestly popular app before paying them a single dime. This makes Parse an exciting and reliable platform upon which to build mobile applications.
Application Data The purpose of any application is, of course, to capture and manipulate data. So far, our users can only create accounts and login to the application, but they can't do anything once they're there. Let's see how the Parse API can help us store and retrieve objects in the Application Domain. We'll start by giving the domain objects strong types. This will let us take full advantage of IntelliSense code verification, and custom business logic. Then we'll add those domain objects to a list on the ParseUser. This will let us store the application data on the backend. It will also relate the data to the user so that they can later fetch the data from the backend. We'll identify domain objects, because Parse doesn't guarantee that a given object will only have one instance in memory. We'll need to recognize when two instances mean the same object. Finally, we'll update the domain objects. Not only will we save changes to the backend, but we'll also cancel changes if the user opts not to save. Let's explore the parts of the API that help us to achieve these goals.
Queries Welcome back to the Parse Mobile Backend with Windows 8. I'm Michael L Perry, and we are going through the steps of building a Windows 8 application on top of the Parse Mobile Backend. We've learned how to store application data on the Parse server and now we're going to learn how to use queries to fetch a set of data from the server and bring it back to the client. When we set up our application data, we stored that data in a property of type IList. In this example, it was an IList of bills. Queries offer several advantages. First, queries fetch all of the objects in one step. When using an IList property, we first fetched the parent object and then fetched each of the children in a separate step. This produced a great deal of calls back and forth to the server. Second, queries allowed us to fetch a subset of objects, whether by matching a condition or by paging. With the IList property, we had to get the entire list. And third, we can join multiple queries together to walk the object graph. If we used IList properties instead, we would have to fetch each intermediate list one at a time, and then walk the graph by going back and forth between the client and the server.
Relations Welcome back to the Parse Mobile Backend as a Service with Windows 8. I'm Michael L Perry. We're learning how to write a mobile application without having to write server code. The Parse API lets us query application data from the client. Now we're going to study relations. Relations represent many-to-many relationships in application data. So far we have one-to-many relationships between a user and his or her bills. We represent this with a Join property of the Bill pointing to the User. The Bill can belong to only one user, but a User can have many bills, so this is a one-to-many relationship. But let's expand the model a bit and suppose that bills belong not to individual users, but instead to families. Now a user can be a member of many families and a family can have many users as members. So the relationship between a User and the Family is many-to-many. Most of the mobile applications you build with Parse will have this kind of relationship, it naturally arises when you share data among many users. Parse gives you two ways to model these relationships. You can use a ParseRelation<T> or you can use a Join Table. We'll examine both of these options to see which one to use when. First, let's take a look at the ParseRelation.
Sharing Welcome back to the Parse Mobile Backend as a Service. We're building a mobile app that stores all of its data in the cloud. So far we've been keeping that data all to ourselves, but now we want to share that data with other users. The Bill Tender application is all about keeping track of my family's bills, so doesn't it make sense then that I would want to invite other members of my family to join me? To do that, I'm going to look them up by email address, and when I invite them to the family I'm going to ensure that our data is secure. Only members of the family should be able to read the bills, and only selected members of the family should be able to manage them. Parse gives us a few tools that we can use to share data with others. Some of these tools like relations and queries we've already seen, but some we're going to use for the first time. These include Access Control Lists or ACLs, which let us specify who should have access to read or to write a ParseObject. We also have Roles, which group together users so that we can assign privileges in aggregate. And finally, we have Cloud Code which runs on the Parse server so that we can enforce additional roles. We'll learn about these new tools and then we'll reconstruct the application with these tools to make it possible to share data with members of our family.
Push Notifications Welcome to module 7 of the Parse Mobile Backend as a Service. I'm Michael L Perry and I've been guiding you through the creation of a Windows 8 application using the Parse Mobile Backend. We've created a very feature-rich application so far, but now we need to focus on topics that are more specific to mobile applications. In this module, we'll cover Push Notifications. Windows has three types of push notifications, Toast, Tile, and Raw. Toast notifications are the messages that fly out from the corner whether your app is running or not. Tile notifications are updates to the live tile, again, whether the app is running or not. And Raw notifications are events that your app receives, but only while it's running. At this time, Parse only supports toast notifications on Windows, so we'll focus on that feature of the API.
Offline Applications Welcome to the final module of the Parse Mobile Backend as a Service with Windows 8. I'm Michael L Perry, and we're wrapping up our journey of building mobile applications using the Parse Services, rather than writing our own. Now we want to make sure that our application behaves appropriately when it's offline and can't reach the server. Mobile devices are offline more often than their desktop or even laptop counterparts. While it's true that Wi-Fi and broadband are more prevalent now than before, they are still not fast enough, reliable enough or ubiquitous enough to be counted upon, so we need to be aware of how our mobile applications behave when they're offline. We'll face two main challenges here. The first is output. Since the Parse server runs all of our queries, how are we to fetch and display data while offline? The second problem is input. We've seen that Parse needs to connect in order to save changes to an object, so what do we do with those changes if we can't connect to the server? To solve the output problem we'll employ local caching. That will lead to another problem for which we will use object recycling. And then to solve the input problem we'll start with queuing. Then we'll run into a snag and we'll add client generated keys. As we explore these strategies, more problems will arise. That's what makes offline applications so hard to write. We don't have enough time in this course to fully explore this base, but these patterns will serve you for most of your offline mobile application scenarios.