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
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
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
In the above snippet, we're passing options to the
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!