Write a custom result set filter to define specific application processing logic. Save the compiled Java class file to location that is accessible from Unwired WorkSpace.
In the custom filter, configure attribute properties so that the returned record set can be better consumed by the device client application. Sometimes, a result set returned from a data source requires unique processing; a custom filter can perform that function before the information is downloaded to the client.
Data in the cache is shared by all clients. If you need to identify data in the cache to a specific client, you must define a primary key attribute that identifies the client (such as remote_id or username).
SELECT * FROM customer WHERE region = :region
As an example, if you want a filter that combines fname and lname into commonName, add MyCommonNameFilter to the MBO. When MyCommonNameFilter.filter() is called, the ''arguments'' input value to this method is a Map<String, Object> that has an entry with the key ''region''. Your filter may or may not care about this parameter (it is the backed database that requires the value of region to execute the query). But your filter may need some other information to work properly, for example the remote user's zipcode. The ResultSetFilter interface includes java.util.Map<java.lang.String,java.lang.Class> getArguments() that you must implement. In order to arrange for the remote user's zipcode (as a String) to be provided to the filter, write some custom code in the body of the getArguments method, for example:
public Map<String, Object> getArguments { HashMap<String, Class> myArgs = new HashMap<String, Class>(); myArgs.put("zipcode", java.lang.String.class); return myArgs; }This informs Unwired WorkSpace that the ''zipcode'' parameter is required, and is of type String. Unwired WorkSpace automatically adds the parameter for the load operation, so this MBO now has two (region and zipcode). Your filter gets them both when its filter() method is called, but can ignore region if it wants.