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:

Initializing the Everlive Client API

On lines 37-45 of our main.js file, we see the following:

When this project was created, I chose the Icenium Everlive Cloud Services project type, and Icenium added these lines for us. The apiKey property on line 39 is the key that connects us to the correct Everlive backend. Also provided for us is the instantiation of the Everlive client API on line 43. Note that our API key is passed in as one of the options – from now on interacting with Everlive via the client JavaScript library will result in communicating to the appropriate Everlive backend store.

User Login With Everlive

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).

What About Logging Out?

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!

User Registration With Everlive

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).

Getting a List of Users From Everlive

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.

Getting Data From Everlive

Everlive's features are exposed via an HTTP service layer, but if you're using the Everlive client JavaScript library alongside Kendo UI Mobile (which our sample application does), you get a nice data-access abstraction in the form of a Kendo UI Mobile data source. The Everlive client library provides an "Everlive" datasource type, which takes care of the underlying plumbing necessary to perform CRUD operations against an Everlive content type. On lines 180-197 in our main.js file, we're creating an instance of an Everlive data source that will be used to retrieve our notes list:

In the above snippet, we're passing options to the kendo.data.DataSource constructor:

• type - tells Kendo UI Mobile to create an instance of the special Everlive type data source.
• schema - we're using the noteModel as a template for local in-memory instances of a note (this allows us to set default fields, field 'types', etc. Check lines 147-179 in main.js for more.)
• transport - the typeName here matches our Everlive Content Type name exactly - wiring this data source up to work against our notes.
• change - a method that's invoked when the contents of our data source change.
• sort - exactly what you think it is: picks a field and direction by which to sort the collection.

Scratching the Surface

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.