Blog.Amit Apple

Consider the next scenario:

You have a Users table and you need to accommodate 2 different views

1. The user gets his own information which includes for example his email.
2. The user can get a list of all users’ names (and only names).

You can do the first simply with the provided samples where using a script you filter the READ users table query to only return the current user’s row.

But for the second you have a bit of an issue, how do you know that the current query is actually for all users?

Well, you can use the custom parameters feature where you pass a custom parameter to the READ script that will tell it you now actually want the “ALL USERS” view (allUsers=true).

The way to pass a custom parameter is by adding it to the request URL as a query parameter:

/tables/users?allUsers=true

On the server-side script this parameter will be available via the request object:

request.parameters.allUsers == true

---

Client-Side Code:

First we write a service filter in order to add the custom parameters to our mobile service client call:

I’ve added a helper method to reduce the code for using this custom parameters:

Then we use it in our code:

---

Server-Side Script:

Here we check for the value of the allUsers custom parameter, “true” we return the names of all users (per query), otherwise we return the current authenticated user (all values of that user):

That’s it…

We can also use these custom parameters for other operations: update, insert and delete in the same way we did for read.