On May 29th, 2013, several of us participated in a webinar covering the new release of Icenium (you can see a recording of the webinar event here). I had a chance to share a bit about Everlive - a new backend-as-a-service offering allowing you to store data and files, manage users and more in the "cloud". As part of the demo, I created a very simple note-taking mobile app and walked us through tying Everlive into it so we could create, store and retrieve notes, as well as register new users to the application and more. Although the app itself is mostly mind-numbingly simple, it's a good reference to get your bearings with Everlive – so feel free to check out the code (available here on github) and watch the webinar.
Let's take a brief moment to highlight the relevant (Everlive) portions of the demo app:
On lines 37-45 of our main.js file, we see the following:
From the above snippet, we can see that we have an instance of the Everlive client assigned to our el variable (probably bad choice of names on my part, but we'll igore that!). The el.Users namespace provides us with some helper methods related to authenticating users. The loginViewModel (our backing state and behavior for our login view) makes use of one of these methods (lines 92-113 from main.js):
On line 97 we call el.Users.login and pass in our username and password. Pretty simple, eh?
You might also notice that login returns a promise, so we're able to continue with additional behavior once we're logged in (and avoid nested callback hell in the process).
It's every bit as simple as login. In our demo app, we have an AppHelper object which contains a logout method (line 56 below):
It doesn't get much easier than this, folks!
Logging in and out isn't much fun if we don't have a means to allow people to sign up to use your app! Fortunately, our sample app demonstrates this as well. Lines 115-144 contain our signupViewModel (backing state and behavior for our registration form):
There's slightly more to explain here, but it's not difficult at all. On lines 132-138 we're creating a Kendo data source that has properties for each field on our registration form and then we're binding it to the form. This way, when the user fills out the fields, our two-way binding will keep the dataSource object up to date with the information from the form. When the user clicks our "signup" button, the signup method (line 117) is invoked and the very first thing we do is call el.Users.register and pass in the username, password and the dataSource containing all of our form data. Like our login method earlier, register returns a promise - allowing us to show a message if our registration is successful (lines 122-124), or an error otherwise (lines 126-128).
Our usersModel (lines 63-90 in main.js) is responsible for getting a list of users from Everlive as well as keeping a reference to the current user. Getting a list of users is as easy as calling el.Users.get() (line 72 below) and getting the current user is as simple as el.Users.currentUser() (line 67). Both methods, as expected, return promises.
In the above snippet, we're passing options to the kendo.data.DataSource constructor:
This sample app really just scratches the surface – in future posts we'll cover working against Everlive directly via the HTTP services as well as some of the other kinds of content which we can store (files, geopoints, etc.). In the meantime, though, I recommend you pull the code down and peruse it, since it will help you quickly see not only how your app can use Everlive for storage and user management, but also how using it in tandem with Kendo UI Mobile takes a ton of boilerplate out of your way!
About the Author Jim Cowart is an architect, developer, open source author, and overall web/hybrid mobile development geek. He is an active speaker and writer, with a passion for elevating developer knowledge of patterns and helpful frameworks. Jim works for Telerik as a Developer Advocate and is @ifandelse on Twitter.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.