Developing for Offline First Mobile Experiences

Editor's Notes

• #9: Before we begin, I want to take some time to share with you why we created Couchbase mobile, and the business problem that we hoped to solve.
• #10: Today’s Mobile Apps ---- Most of today’s mobile apps are designed so that any remote data, whether downloading records from a server or uploading your local data, requires the network to be available and online. As long as that’s the case, and the Internet connection is fast enough, and there aren’t any problems, then the app performs exactly as expected—and that’s great. But as soon as the network begins to degrade, say we’re down to just a couple of tower bars, or the Wi-F is having a bunch of latency—that sort of thing—then we start to see the app’s user experience break down. That’s when we see the progress notification UI hints show up, the spinners, the waiting. If things get bad enough, we will see an error message saying that, “I’m sorry you can’t do what you were trying to do right now, you’ll have to try later.” Whatever work you were doing is lost, and the end result is a user who is unhappy and dissatisfied and can use your app.
• #11: How Does This Affect What People Think? ---- how do you know if you’ve got these kind of problems? Well, it’s reflected in your app store rating. We’ve all seen apps in the one and two star category, with user reviews saying that the app doesn’t work or it’s slow.
• #12: How Does This Affect App Uninstall Rates ---- Besides the bad brand PR, why should you care? Because people delete poorly performing apps. Let’s look at application uninstall rates. Why do people delete an app from their device? The top three reasons are: freezing, crashing, and slow responsiveness. And in the case of freezing and slow responsiveness, those are directly tied to how we build our application. More often than not, our networking code is the culprit. In a lot of cases we can’t control the environment where people are using our app, but if we’re using proper coding strategies, we can mitigate those issues.
• #13: Slide 10 - Data Location is the Problem
• #14: Slide 11 - Local Data + Sync is the Solution
• #17: We have two core products in Couchbase mobile. We have Couchbase Lite, which runs on the device And we have Sync Gateway, which stands on the border between your private cloud and the public cloud.
• #18: We have two core products in Couchbase mobile. We have Couchbase Lite, which runs on the device And we have Sync Gateway, which stands on the border between your private cloud and the public cloud.
• #22: Sync gateway also handles the permanent persistence of your applications data in your Couchbase Server cluster that lives in your private data center. So as your device is syncing with sync gateway and pushing your data up, sync gateway is also writing that data into the permanent data store, backed by our highly scalable Couchbase Server technology. Now, let’s look at security layer concerns: in this particular case, authorization.
• #36: Creating a Database ---- cblite.getURL is the only available plugin function. Use the URL to create a new ng-couchbase-lite object and assign it a database name. All requests will go against this URL and database including the “createDatabase” function.
• #37: Inserting Documents ---- Show that you can take a JavaScript object and insert it directly into Couchbase Lite without any further manipulations. Database transactions return promises to remain asynchronous.
• #38: Couchbase Lite Views ---- Elaborate the differences between HTML5 local storage and NoSQL. With HTML5 local storage you’re probably going to serialize all data into a single property. This single property is going to become quite large and hard to maintain, but you’re going to do your lookups with that one key name that you probably remember. With NoSQL documents you’re going to have many documents which you probably won’t remember the key names for. To get all these documents you’re going to need to design a view for querying them. In the case of the Todo Lite example, there are two views. A view for querying lists and a view for querying the tasks that exist in a list.
• #39: Querying Couchbase Views ---- Querying the “lists” view will return all lists, but of course in a promise to remain asynchronous. You also have the option to pass a start key, which is obvious in the example of querying the “tasks” view. You don’t want to query all the tasks, only the particular tasks that go with a list.
• #40: Replication With Sync Gateway ---- When replication starts, it will asynchronously happen in the background. In this example, replication will continuously happen, pushing all local changes to the sync gateway. Once local starts replicating up, we also replicate the sync gateway down to local. We are starting two replication processes.
• #41: Listen for Changes ---- The “listen()” function of ng-couchbase-lite will broadcast any changes it picks up by doing continuous long-polls against the API. Changes include those done locally and remotely. Anything broadcasted can be picked up in AngularJS with the “$on” method of “$rootScope”. Broadcasted information is in array form with properties that contain ID and “possibly” a deleted property to signify that a document has been deleted
• #44: Demo Time ---- Sync Gateway URL: http://localhost:4985/_admin/ Simulator IP: 192.168.56.1 Sync Gateway Port: 4984
• #48: Couchbase Labs on GitHub ---- A fully functional example project is available for download on GitHub.