Home > Archive

Handling expired tokens in your application (Day 11)

UPDATE: My buddy Carlos created an updated article that shows how to use the replacement for ServiceFilters in managed clients, check it out: Caching and handling expired tokens in azure mobile services managed SDK

On day 8 we looked at how you can generate your own Mobile Services JWT tokens to create a custom identity. One thing you may have noticed is that the JWT has an expiry, meaning that at some point the user’s authentication token will become invalid. In day 10’s post we also looked at an approach that would allow you to cache the user’s token to save them logging in repeatedly. However, the combination of an expiry and a cached token have an obvious downfall – what happens when it expires? Well, you have to log your user back in, obviously.

So you need to be ready to receive a 401 unauthorized response and log the user back in. But, you probably don’t want to write this code every time you call Mobile Services, right? Enter filters which we covered in Day 3. Filters allow me to intercept calls to and responses from the Mobile Service for any given client instance. This will allow us to inspect the response for a 401 response, trigger the login flow and then, best of all, automatically replay the request that was rejected with a 401.

Here’s the code for C# / Windows 8:

As you can see, all this filter does is inspect the response for a 401 status code. If the call was unauthorized, we log the user in again and then attach the new authentication token to the original request (by modifying the header). Resend the request and then send the response back to the consuming code, as though nothing happened!

You can also do this on iOS / Objective C:

The iOS implementation assumes it’s safe to grab the current rootViewController (from the current UIApplication delegate’s  window). This may not be the case for your application. In reality, you’d probably want to take this concept and use it to trigger your logout/login presentation (e.g. via NSNotificationCenter). I’ll leave this as an exercise for the reader as it is likely to vary by application.

From now on, I’ll be using this in all applications as my primary login flow as it composes extremely well with cached credentials. Join us again tomorrow for the last day of the twelve days of ZUMO.

Josh Post By Josh Twist
10:28 PM
31 Dec 2012

Setting the auth token in the Mobile Services client and caching the user’s identity (Day 10)

On Day 8, we looked at how you can generate your own ZUMO authentication token. The good news is, if you do want to generate your own tokens (say you want to create a private identity system or integrate with ADFS) then you can still use the Mobile Services client to work with your tables (and logout will still work too!).

All you have to do is manually ‘log the user in’ rather than use the built in login methods. To do this, you just need to set the user object on the Mobile Service client instance, here’s how – in C#, JS and Objective C:

So if you build your own login mechanism, you’re not forced to build your own client. And what’s more, many people want to cache the full identity of their user so they don’t have to login each time the application starts. This is entirely possible now, all you have to do is store the user ID and authentication token locally on the machine*. Next time the app starts, you check the cache and if these values are available, you skip the login flow and rehydrate the client with this data.

Be careful though, the authenticationToken is sensitive data and ideally (depends on the nature of your application and the data it stores), if you store this on the device you should store it encrypted so that should the device get stolen, the bad guy can’t read the value off the disk and use it. Fortunately, Windows and iOS both provide mechanisms to help with this, checkout Windows’ Credential Locker and iOS keychain.

This was day 10 of the twelve days of ZUMO.

Josh Post By Josh Twist
3:22 AM
31 Dec 2012

Fetching a basic user profile in Mobile Services (Day 9)

When building an application that has users authenticate, you often want to augment that user data with some kind of profile. Perhaps a nickname or real name, or a location. We collect this in the doto sample, and we also use the technique I’m going to post about here today.


Above you can see the registration screen in doto, but this is how it appears when you open the app, because we prefill the data based on your Microsoft Account profile when you login. This is a nice gesture for the user, as most will accept the defaults but for those that want to represent themselves differently in your app – they can customize the name.

Today, I want to share some server code that can help you do the same based on your public Twitter and Facebook profiles if your user logs in via Twitter or Facebook. The idea behind the simple function fetchBasicProfile below, is that you can simply pass in the user object in your Mobile Service server script, and it will invoke your callback with a simple profile object that has common properties for both Facebook and Twitter (which has wildly different basic profile structures available). Here’s the code:

And that includes a test you can run using Mocha JS (see day 7 for more on this).

The properties returned in the basic profile are:

  • name – the full name of the user, e.g. Josh Twist
  • firstName – the first name, e.g. Josh (not available on Twitter)
  • lastName – the surname or family name, e.g. Twist (not available on Twitter)
  • userName – a username specific to the source, e.g. @joshtwist or joshtwist
  • smallImageUrl – a url to a small (~50x50) profile image
  • largeImageUrl – a bigger image (~200x200)
  • source – the source of the information, e.g. Facebook or Twitter
  • id – the id of the user in the source system, usually a large number

It’s super easy to use and you can just paste this function into any of your scripts that want to do this.

This was day 9 of the twelve days of ZUMO. Join us tomorrow for day 10.

Josh Post By Josh Twist
11:49 PM
29 Dec 2012

Generating your own ZUMO auth token (Day 8)

Most developers using Mobile Service are familiar with Mobile Services authentication – which makes it uber easy to sign your users in to your Mobile Service via Twitter, Facebook, Google and Microsoft Account. When we sign a user in, we issue the client a ZUMO JWT token that is used to identify that user on subsequent roundtrips via the X-ZUMO-AUTH header, as documented in our HTTP API reference.

A JWT, or JSON Web Token, is a simple token formed of three sections separated by ‘.’

The first section is the JWT header which declares that the thing is a JWT and  the encoding used by the signature.
The second is the claims set, which is where you put any claims. In the case of Mobile Services, this is where we put the userId.
The third is the signature, which is used to ensure that nobody has tampered with the first two sections.

Because the signature is generated using a secret key, we know that it must have been created by somebody who has the secret key (and therefore we trust them). In the case of Mobile Services, this is your Master Key.


You can access the master key by clicking on the MANAGE KEYS command in the DASHBOARD and QUICKSTART tabs of the Windows Azure portal.

Since you have the access key, and know how to create JWTs, there’s nothing stopping you from creating your own Mobile Services tokens for your users, if you want to add an additional authentication mechanism for example. We have always kept an eye on composition with other services in Azure (and beyond) and this is a great scenario. For example, imagine you have your own identity system with usernames and passwords for your existing website. Then you could easily add code to that site to create a Mobile Services auth token to allow clients to access Mobile Services with a custom provided identity.

Here’s some JavaScript that can be used in nodeJS (or even in a Mobile Services server script) to generate a ZUMO JWT:

And to test it out, try creating a table in Mobile Services and setting the READ permission to Authenticated User only, now hit it with CURL or Fiddler and some random x-zumo-auth header:

curl –H “x-zumo-auth: randomgoop” https://yourservice.azure-mobile.net/tables/foo

Which will result in a 401 unauthorized response “The authentication token’s signature was malformed or signed by a different key.”


However, with a genuine token generated by the zumoJwt function as follows:

var expiry = new Date().setUTCDate(new Date().getUTCDate() + 1); // expires in one day from now 
var jwt = zumoJwt(expiry, "your-aud", "unique string for this user", "yourmasterkey");

curl –H “x-zumo-auth: JWTHERE” https://yourservice.azure-mobile.net/tables/foo

Then you’ll get some data! What’s more, on the server if you inspect the user parameter in a script, you’ll see that the userId property, is the userId you specified in the JWT.

This was day 8 in the series, the twelve days of ZUMO.

Josh Post By Josh Twist
11:36 PM
28 Dec 2012

Unit testing Mobile Services scripts (Day 7)

Many developers are big fans of unit testing. I’m a big fan of unit testing, especially when authoring algorithms or tight routines with few dependencies. The ROI for that kind of code is huge; in fact, in this situation a unit test is often the easiest and cheapest way to test your code. It’s not that often that I end up writing that kind of code when building Mobile Services (though it does happen) and when I do, I want unit tests.

The first time I did this I simply split my code into multiple functions and created a unit test to execute certain functions. Here’s an example using the Mocha testing framework for JS (id TDD mode)

var assert = require('assert');

// the function I'm testing
function add(a, b) {
    return a + b;

// my test suite for the calculator
suite('calculator', function() {
    // a test in my suite
    test('add', function() {
        // the test
        var result = add(1, 2);
        // my assertion
        assert.strictEqual(result, 3);

If you’ve done any unit testing before, this should look familiar – the notion of suites containing tests that pass or fail. I can install mocha using npm (see this post to get you started with node and npm).

npm install –g mocha

And then you can run your tests

mocha test.js –-ui tdd

And you’ll get your results:


Easy, and all green! My add function could easily be more complicated (insert your prime number or fibonacci code) and this is a great way to get any complicated functions working before I use them in my Mobile Service. One place where unit testing gets weird is async. Javascript async is typically handled using callbacks (especially in node) so let’s imagine if our add method was async:

function add(a, b, callback) {
    setTimeout(function() {
        callback(null, a + b);
    }, 500);

Note that I added a delay of 0.5s to make it _really_ async. Now to test this we need to tell Mocha when we’ve done waiting for the async and are happy to declare the test passed. Here’s our code:

suite('calculator', function() {
    test('add', function(done) {
        add(1, 2, function(e, result) {
            assert.strictEqual(result, 3);

Notice how we specify the ‘done’ parameter in the test function. This informs Mocha that this is an async test and it should wait for me to call ‘done()’. Smart eh?


Notice how this test took a while longer (just over 500ms). Now that we’re grounded in Mocha and testing functions – what if I wanted to test my actual scripts? You know, the insert and read methods, for example?

In this case, you will have to do a little mocking of the Mobile Service request object (and possibly the user and query objects, depending how complicated you want to go) but it’s pretty simple. Let’s recap the request object:

request.execute() – when called with no parameters means go ahead, I’m done with any changes to the request – get on with it!

request.execute({ success: fn }) – call my success function and don’t send the response to the client, the consumer will do that now

request.respond() – send a response to the client with the canonical HTTP status code and JSON body for this operation

As an example, imagine we have an insert script that encrypts the value of a particular property (text) and a read script that decrypts it – this means this value is encrypted at rest in your SQL database. How could we test that?

And there you have it, some tests that can execute against your Mobile Services scripts allowing you to develop locally and be really sure your stuff works. Combine this with this post and you are getting really deeply serious about your Mobile Service workflow.

This was Day 7 of the twelve days of ZUMO – we’ll be back again tomorrow for Day 8.

Josh Post By Josh Twist
11:22 PM
27 Dec 2012

A Mobile Services Log Watcher (Day 6)

The last few days I’ve been exploring the CLI and doing a bit of NodeJS code at the same time. Today, I want to continue on that theme and fulfill a real scenario that my friend and colleague Mike Taulty asked about a few months ago. Mike asked (paraphrased): “It would be cool if there was some tool that would receive or poll for logs so, during development, I can just refer to my log watcher window to see that latest logs. Is there a way I can do that?”. Today, we’re going to use the new CLI and node to build this.

First, you’ll need node installed and ready to go. You’ll need this in the coming days of this series so go get it now. I have detailed instructions in this post: Getting started with the CLI and backing up your scripts (Day 4)

Once again, we’re going to use NodeJS to write a small console program that will invoke the CLI to poll for logs for a given service, and only show new logs since the last poll. One of the great things about using NodeJS for this is that it will work on both Windows and Mac.

This is the node script that I saved into a log.js file:

The script is pretty simple if you’re familiar with the script that we created in yesterdays post: More CLI – changing your Mobile Services workflow (Day 5)

The main function is the executeJsonCmd which invokes an Azure Mobile CLI command and adds the --json switch to make the CLI return JSON. We then parse that into JSON that we can process inside Node. The rest of the code is mostly formatting and a little ‘polling….’ animation so you can see when we’re invoking the CLI. The command we use to get the logs for your service is

azure mobile log <servicename> 

And, as you might expect, to start our little node app running you just need to copy this in a js file (called log.js here) and invoke

node log.js <servicename>

From your node.js command prompt (or Terminal in Mac). The LogWatcher will then poll for logs every 10 seconds, but you can tune this to your pleasure by adjusting the pollingInterval variable at the top of the script (heeding the warning in the comments). Here’s some example output:


This day 6 of the twelve days of ZUMO. Tune back tomorrow for more!

(and Happy Boxing Day to Mike and my UK readers!)

Josh Post By Josh Twist
10:52 PM
26 Dec 2012

More CLI – changing your Mobile Services workflow (Day 5)

In yesterday’s post Getting started with the CLI and backing up your scripts (Day 4) we looked at how you can use the new Azure Cross-Platform CLI on Windows, Mac and Linux to work interactively using the command line and automate certain scenarios.

In today’s post I want to push that scenario a little harder and understand how this might change our workflow when writing Mobile Services scripts. The post yesterday showed how to use bash to backup your server scripts, how to install Node and use NPM. Today, we’re going to use a small node program to allow us to work on scripts using our favorite text editor and automatically upload my scripts whenever I make changes to the files locally.

The idea is simple. We create a node script that pulls all scripts down to a given directory (like yesterday, but we’ll use NodeJS) and then watches that file system for any changes. If a .js file changes we’ll upload it back to the server.

Before you do this, you’ll need to install node and import your .publishsettings file so you’re ready to start scripting – the steps are detailed in yesterday’s post.

Here’s the complete node script that we’ll be using today:

In order to run this node program you’ll need to pull in Mikael’s watch module. Of course, you can use NPM to do this: npm install –g watch

The –g switch will install globally so you can easily use the module anywhere. Then, you’re ready to go. Save the app.js file somewhere and launch it with the following command line arguments:

node app.js servicename /Directory/To/Files

The two arguments are

  1. The name of the Mobile Service
  2. The folder, into which the table scripts should be downloaded and monitored.

Note this also works identically on Windows and Mac:


Once the files have been downloaded (they will be downloaded each time and will replace any existing files) you can open the file up in your favourite text editor, like Sublime 2:


And now, whenever I save a change to this file it will be automatically uploaded to the Mobile Service ready for testing. This is cool, and a big boost for those who want to edit files locally.

As an exercise for the reader, it would also be very easy to setup git with a bare repository and a hook that pulls the latest files into another directory. You could watch this directory in much the same way as I demonstrated with this script, giving you yet another workflow:

Work on files => push to git repo => automatically push to Mobile Service

I'd think of this code as nothing more than experimental in quality so use at your own risk, of course.

Enjoy! I hope this wasn’t the best Christmas present you received today (for those to whom that particular holiday applies) but I hope you like this all the same. Join us again tomorrow for another post as part of the twelve days of ZUMO.

Josh Post By Josh Twist
4:27 PM
25 Dec 2012

Getting started with the CLI and backing up your scripts (Day 4)

One of the things I love about Mobile Services is the zero-friction, no impedance approach to development. It just feels so much fun to fire up a new service, start scripting and have a custom API in the sky in a matter of minutes.

Sometimes, I do this and before I know it (literally within 30 minutes) I have a pretty advanced service and a bunch of scripts that I’d really hate to lose. And, whilst I feel great that my data and scripts are safely stored in Windows Azure, it’s still entirely possible for me to lose that work by doing something silly like accidentally deleting the whole mobile service.

Wouldn’t it be cool if I could easily backup my mobile services scripts? Yes. Well, enter just one cool possibility created by the CLI that Scott announced in his post the other day.

In case you didn’t catch it, here’s a quick overview…

We recently added Mobile Services support to the Azure Cross-Platform CLI. You can see all of the code that powers this thing on github. Yup, it’s sweet, sweet open source.

To run and install the xplat CLI you’ll need node. Since Mobile Services runtime runs in node this is a great thing to have on your machine already, so go get it: install nodeJS.


Seriously, install it now because we’ll need it later in this very series!

And once you’re done, you can start to use node and NPM. If you’re not familiar, NPM is Node’s Package Manager. .NET guys can think of it as NuGet for NodeJS; iOS guys can think of it as CocoaPods for NodeJS.

NPM is also the way you install the azure xplat CLI. Open the (freshly installed) Node.js command prompt:

IMPORTANT, all of these commands work identically in terminal on the Mac.


And once opened you can execute the necessary npm command: npm install –g azure-cli


Once done, you can start to use the azure commands. The first thing you’ll need to do, is import your publishsettings to allow you to securely connect the your azure services. There’s even a CLI command to help you with this. Just type:

azure account download

This will pop a browser window that will help you download your publish settings for your azure subscription(s).


Note that you may need to login to your azure account here. Once done, you’ll be presented with a download of a file with a .publishsettings extension. Save this somewhere memorable and safe because it contains the key to manage your azure services. The next step, is to import this:

azure account import .\path\to\your\download.publishsettings

This will have you all setup, to test, why not list your mobile services using

azure mobile list


Very cool! Now, let’s get on to backing up our scripts. I mentioned above that everything we’ve done so far works great on Mac and Linux, so let’s use some of those built in terminal commands to start our backup. The ideas is easy, we’ll be using these two commands

azure mobile script list <servicename>
azure mobile script download <servicename> <scriptname>

The first will list all of your scripts (include scheduled etc) and the second can download the script. Great, so we can download all our scripts to a local folder in bash with this simple script:

azure mobile script list <servicename> | grep 'table/' | awk '{system("azure mobile script download <servicename> "$2)}'


And you’re done! You’ll now have a folder ‘table’ with all your scripts:


You can use exactly the same on a Windows machine if you have a bash terminal (chances are you do, if you have git installed). Here’s the same command running on Windows and my files, thanks to gitbash!


This was day 4 of the series: the twelve days of ZUMO. We’ll be back tomorrow pushing the CLI even harder!

Josh Post By Josh Twist
11:46 PM
24 Dec 2012

Filter this (Day 3)

One of my favorite hidden nuggets in Mobile Services is Service Filters. Service Filters allow you to place an interceptor between your client’s CRUD calls and the server. There are many useful applications for this, but one of my favorites is the ability to easily create a ‘busy’ or ‘activity’ indicator based on in-flight requests to the your Mobile Service. Here’s how in C#:

public class MyServiceFilter : IServiceFilter
    private int _callCount = 0;
    private Action<bool> _busyIndicator;

public MyServiceFilter(Action<bool> busyIndicator) { _busyIndicator = busyIndicator; }

public Windows.Foundation.IAsyncOperation<
IServiceFilterResponse> Handle( IServiceFilterRequest request, IServiceFilterContinuation continuation) { return HandleAsync(request, continuation).
AsAsyncOperation(); }

private async Task<IServiceFilterResponse> HandleAsync( IServiceFilterRequest request, IServiceFilterContinuation continuation) { // update the count by one in a single atomic operation. // If we get a 1 back, we know we just went 'busy' var outgoingCount = Interlocked.Increment(ref _callCount); if (outgoingCount == 1) { _busyIndicator(true); }

IServiceFilterResponse response = await continuation.Handle( request).AsTask();

// decrement the count by one in a single atomic operation. // If we get a 0 back, we know we just went 'idle' var incomingCount = Interlocked.Decrement(ref _callCount); if (incomingCount == 0) { _busyIndicator(false); }

return response; } }

The first step is to implement the IServiceFilter interface from the Microsoft.WindowsAzure.MobileServices namespace. There is just one method to implement called Handle. In the code above,  I simply delegate to HandleAsync to keep the code somewhat cleaner and allowing me to use .Net’s awesome Task framework. HandleAsync is where all the magic happens.

Inside HandleAsync, we know we have an outgoing call about to be started to increment the filter’s in-flight call count by one. If the call count is 1, we know we just went from no inflight calls to some, so we call the ‘busy’ delegate.

Next we actually invoke the server by calling Handle on the continuation parameter. Thanks to the awesome await keyword, we can keep our incoming response code right inline in the same method, and this is where we decrement the filter’s call count. If we have a new total of 0, we know we just went ‘idle’ and invoke the busy delegate with a value of false.

It really couldn’t be easier!

And now, to consume this filter we have to wrap our MobileServiceClient instance as follows:

var filter = new MyServiceFilter(busy =>
      // update the status of the busy indicator based on the status change
      progressControl.Visible = busy ? Visibility.Visible : Visibility.Collapsed;

// use the newClient instance for all operations that should use busy tracking
var newClient = originalClient.WithFilter(filter);

You can also use filters in our WinJS client and the Objective C client for iOS. If you checkout the iOS quickstart you’ll notice that you get a sample implementation for free.

iOS (Objective C)

In iOS, using a service filter is as easy as implementing the MSFilter protocol, here’s an example:

- (void) handleRequest:(NSURLRequest *)request
    // A wrapped response block that decrements the busy counter
    MSFilterResponseBlock wrappedResponse = ^(NSHTTPURLResponse *response, 
NSData *data,
NSError *error) { [self busy:NO]; onResponse(response, data, error); }; // Increment the busy counter before sending the request [self busy:YES]; onNext(request, wrappedResponse); }

And then in the same class, we have a busy method:

- (void) busy:(BOOL) busy
    // assumes always executes on UI thread
    if (busy) {
        if (self.busyCount == 0 && self.busyUpdate != nil) {
        self.busyCount ++;
        if (self.busyCount == 1 && self.busyUpdate != nil) {

To see this in action, just try the iOS quickstart


This was Day 3 in the series The twelve days of ZUMO. We’ll have more tomorrow.

Josh Post By Josh Twist
1:53 AM
24 Dec 2012

It’s time for CRON (Day 2)

The scheduler (or CRON) is one of the features I've been most excited about us bringing to Mobile Services for some time. The need to execute code on a scheduled basis is such a common requirement that it feels great to bring the Z-factor experience to this problem.


Creating a new CRON job is super-easy. Inside your mobile service click on the SCHEDULER tab and click the CREATE button at the bottom of your screen. Setting up a schedule is so stupidly easy that I won't explain the intimate details here. However, note that you can setup a job without a schedule. This is handy if you want to start scripting before you know the schedule or, perhaps even more interestingly, you want to create a script that you can run "on demand".

This makes for a great place to keep a cleanup script, particularly handy for a demo (although you should wait until we cover the CLI in this series for the most bang there). One of my favourite uses for the scheduler's Run Once feature is the ability to quickly test and play with push notifications for your Windows 8, Windows Phone 8 or iOS device. Here's how to have some fun with push using run once.

First, you'll need to configure your application to receive push notifications - that's beyond the scope of this article but you can easily follow these tutorials to setup your Windows 8, Windows Phone or iOS app. Then you need to get a channel (or device token) for the push;

Windows 8

Once your app is all setup, quickly grabbing a channel URL for test purposes is a doddle

 var channel = PushNotificationChannelManager.
CreatePushNotificationChannelForApplicationAsync(); Debug.WriteLine(channel.Uri);

And then you can grab the channel from the output window with a simple cut and paste.


Head over to your new ‘on demand’ scheduled task and enter the following code (don’t forget to configure the service with the Package SID and client secret also).

push.wns.sendToastText04("https://channel-url-here", {
   text1: "Hello",
   text2: "This is a test",
   text3: "bananas"

And you should get your toast notification if everything is setup right.

Windows Phone:

Again, the flow is similar, but acquiring the channel is a little different:

var channel = HttpNotificationChannel.Find("MyPushChannel");

if (channel == null)
    channel = new HttpNotificationChannel("MyPushChannel");


And then to send the push:

push.mpns.sendToast("https://channel-url-here", {
    text1: item.title,
    text2: item.subtitle


First, you’ll need to request regisration (in the AppDelegate.m):

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:
(NSDictionary *)launchOptions
    // Register for remote notifications
    [[UIApplication sharedApplication] registerForRemoteNotificationTypes:
    UIRemoteNotificationTypeAlert | UIRemoteNotificationTypeBadge 
| UIRemoteNotificationTypeSound]; return YES; }

And subsequently handle the token and output to the log window:

- (void)application:(UIApplication *)application
didRegisterForRemoteNotificationsWithDeviceToken: (NSData *)deviceToken { NSLog(@"%@", deviceToken); }

You can then grab that token (without the angle brackets <>) and add to the following script

push.apns.send("your device token here", {
   alert: "Hello world";

Now you’re setup, hit that Run Once button. A great way to test push!


Oh and don't forget that you can actually schedule scripts too! Which makes scheduler great for:

  • periodically cleaning or archiving old data
  • aggregating data from a Mobile Services table or an external source ready for a report
  • poll another service and notify your users about events, e.g. stock prices or twitter activity
  • use CRON to roll multiple push notifications together to avoid interrupting users too often

Let me know in the comments or on twitter if you have any cool scenarios for the scheduler.

Josh Post By Josh Twist
8:01 PM
22 Dec 2012

Delete records and truncate tables (Day 1)

Today Scott posted about a stack of new improvements to Mobile Services. In fact, there were so many improvements in the latest Azure release that there wasn't room to discuss one of my favorite new features.


If you take a look at any of your Mobile Service tables and navigate to the BROWSE feature you might notice a new button called TRUNCATE. During development of your mobile service (or if you're preparing to give a demo) it's very common that you want to delete all records from one of your Mobile Service tables. That's what TRUNCATE will do, leaving all your scripts and permission settings intact.


Another common thing to want to do during development of your service is to delete a single row. Perhaps your testing your user registration system and want to delete that user or profile record so they go through your registration workflow again. Now, all you have to do is select the row and a DELETE RECORD button will appear. BINGO!

It's a small improvement but makes a big difference.

This post was Day 1 in the series: the twelve days of ZUMO. Join us tomorrow for Day 2 of the twelve days of ZUMO when we'll take a look at another new feature, the scheduler.

Josh Post By Josh Twist
1:40 AM
22 Dec 2012

The twelve days of ZUMO

It's been a great year for the Mobile Services team. 2012 was the year that most of the team that built the product joined (the project was only conceived in late 2011 and there were very few members of the team at that point) and we shipped our first public preview in August. Since then we've been adding more and more feature and more locations on a regular basis.

Just today, Scott blogged about the addition of a serious new feature in our scheduler which allows you to setup CRON jobs to run server scripts AND we added a european datacenter to our available locations.

To celebrate this, and the fact that we made it through the end of the world OK (21 Dec 2012, or at least it seems so far) I wanted to start a series of blog posts. And the series should have a festive theme to see us out for the year. So with that, let's begin the twelve days of ZUMO:


Day 1: Small but great enhancements to the data browser

Day 2: It’s time for CRON

Day 3: Filter this

Day 4: Getting started with the CLI and backing up your scripts

Day 5: More CLI and changing your Mobile Services workflow

Day 6: A Mobile Services Log Watcher

Day 7: Unit testing Mobile Services scripts

Day 8: Generating your own ZUMO auth token

Day 9: Fetching a basic user profile in Mobile Services

Day 10: Setting the auth token in the Mobile Services client and caching the user’s identity

Day 11: Handling expired tokens in your application

Day 12: Exploring custom identity in Mobile Services

Josh Post By Josh Twist
1:23 AM
22 Dec 2012
© 2005 - 2018 Josh Twist - All Rights Reserved.