Using Virtual Tables for Different Views – Windows Azure Mobile Services


Building on my last post (Move Your Client Logic to the Server - Windows Azure Mobile Services) I will show you how to create a Virtual (or dummy) table to give you a different view of your TodoItem table.  This Virtual table will not contain any records however.

In this case, let’s assume you did not want to change your TodoItem table read script because you do need the full table with complete items elsewhere in your application.

Start by returning the read script back to it’s original form.

Navigate to the TodoItem read script and hit the ‘Clear’ icon at the bottom of the page to restore the script:

image

 

Your Read script should only contain the request.execute(); method as it originally did.

Next define a new table called ‘todoitemcomplete’ by choosing the CREATE icon in the DATA tab:

image

Be sure to set the appropriate permission levels as well

 

image

Next we will modify the four server scripts to use the TodoItem table and not the newly created table for their operations.

Here is the read script (actually the only one used in my example):

 

function read(query, user, request) {

    var todoItemsTable = tables.getTable('TodoItem');
    todoItemsTable.where({ complete: false }).read({ success: respondOK });
    function respondOK(results) {
        request.respond(statusCodes.OK, results);
    }

    // no! request.execute();
}

The next step is to setup for reading from this dummy table an mainpage.xaml.cs:

 

    //Strongly typed class for dummy table is same structure as old table
    public class TodoItemComplete: TodoItem
    {
        
    }

    public sealed partial class MainPage : Page
    {
        //Changed the items collection to the new class
        private MobileServiceCollection<TodoItemComplete, TodoItemComplete> items;
        //Added a reference to the dummy table 
        private IMobileServiceTable<TodoItemComplete> todoTableComplete = App.MobileService.GetTable<TodoItemComplete>();
        //For now... keep a reference to the old table for Update and Insert operations
        private IMobileServiceTable<TodoItem> todoTable = App.MobileService.GetTable<TodoItem>();

 

Fix up any references that used a TodoItem in this collection by casting to a TodoItemComplete such as this:

  items.Add(todoItem as TodoItemComplete);
  items.Remove(item as TodoItemComplete);

 

And change the RefreshTodoItems() to use the new todoTableComplete:

private async void RefreshTodoItems()
        {
            MobileServiceInvalidOperationException exception = null;
            try
            {
                // This code refreshes the entries in the list view by querying the TodoItems table.
                // The query excludes completed TodoItems
                items =  await todoTableComplete.ToCollectionAsync();
                //items = await todoTable.ToCollectionAsync();
            }

 

Now you have a Virtual table that will give you a view of complete items only with the logic on the server.

Further Discussion

I only discussed the Read script but you can extend this to the other scripts.

This has the downfall that the query parameters passed to the Read (if any) are difficult to extract and pass on to the table read.

A better option may be to use parameters in the query for the special cases (see my next post).

Let me know if this was useful to you!

 

-Jeff

 

 

Ref: http://www.windowsazure.com/en-us/develop/mobile/how-to-guides/work-with-server-scripts/#access-tables

Comments (6)

  1. Miguel says:

    This is useful, but have a question regarding incrementally reading more items:

    In a normal read() request to a "native" SQL Azure table, the mobile services client handles incrementally loading more items.

    For instance, in C# we get back a MobileServiceCollection when doing .ToCollectionAsync()

    If you "re-wire" the server-side to use a different table on read(), as you just did in this example, does this still work the same?

    Do we still get back a collection that supports "pagination" ?

    If so, I'm actually curious on how that's implemented!

  2. Sergey says:

    A good question Miguel. +1

  3. Jeff Sanders says:

    Extremely easy to test, right guys?

  4. Jeremy BP says:

    Hi Jeff,

    I was thinking about doing the same in a .Net backend. Something like Where(a => a.UserId == currentUser.Id) to filter result server side.

    For exemple, if you have a table with all records from all users and you want a view like MyRecords to get the current logged in user records, how would you proceed?

  5. Guy says:

    Hi Jeff! Any chance you can update us on how to implement on the latest App Service Editor? I am not familiar with Node.js and am struggling to figure out how to refactor this.

    1. Jeff Sanders says:

      I will work on that!

Skip to main content