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).
This interface defines how a custom filter for the data is called.
For example, this code fragment sets the package name and imports the required classes:package com.mycompany.myname; import java.sql.ResultSet; import java.util.Map;
If you choose to implement this interface, you must instead execute a chain of mobile business object operations and filters with real data before you can get actual results of the output columns and their datatypes. This can impact information on the data source, which may eventually need to be reverted. By first implementing these interfaces, the operation does not need to be executed first. Instead, the getMetaData obtains the necessary column or data type information.
This example sets the package name but uses a different combination of classes than in the example for step 1:
package com.mycompany.myname; import java.sql.ResultSetMetaData; import java.util.Map;
ResultSetFilter filters the data in the first option documented in step 1. Each filter defines a distinct set of arguments. Therefore, use only the arguments with the appropriate filter that defines these arguments in getArguments(), rather than use all filters and data source operations.
The result set passed in contains the grid data, which should be considered read-only—do not use operations that change or transform data.
public interface ResultSetFilter { ResultSet filter(ResultSet in, Map<String, Object> arguments) throws Exception; Map <String, Class> getArguments(); }
public interface ResultSetFilterMetaData { ResultSetMetaData getMetaData(ResultSetMetaData in, Map<String, Object> arguments) throws Exception; }
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.