Function Items

There are 4 types of function item types that can be specified, each with a different purpose. The good news is that on the iOS client end, as long as you implement the LDMSearchResultsDelegate correctly, and have your UI use the LDMSearchResults base class, then you have nothing to worry about. First let's break down what a function item is composed of.

"data": {
    "function": "select * from _entity_Account t where t.accountId ='%?'",
    "functionId": "TestFunction",
    "functionName": "Test Function",
    "functionType": "/Function/functionType[SQL]",
    "itemType": "Account",
    "clientConfig": "",
    "functionParams": [
      "Account.accountId"
    ]
  }

• function: the actual SQL, each function type has a different expectation for this field, so please detailed sections below. When filling this in, there is no need to fill in the community name for the full table name as the system will take care of that
• functionId: primary key of the function item
• functionName: a user friendly name for the function
• functionType: SQL, DynamicSQL, RDSQuery, QueryAPI
• itemType: The item type you expect to be returned
• clientConfig: Used for additional parameters that the client may use
• functionParams: an array of strings, used to populate the function where appropriate.

Any given time in the actual function param, your SQL may contain the following string: %?. During run time, the application will replace the string with results specified in functionParams. This is an array of strings, but is expected to contain either a method from LDCFunctionManager or something in the context. More information about this is available at the bottom of this section.

Function Type: SQL

Queries Against: Local Database

This is the most basic type of function item. The query is automatically limited to return 250 results and there is no pagination support. This function type is only appropriate when you are sure the result set to be very small (under 250 items).

Function Type: SQLiteQuery

Queries Against: Local Database

This is a more advanced version of the SQL function type. This type supports pagination and automatically limits each page to 250. This function type is recommended when querying large sets of data against the local database and the expected UI is a table / collection view. The function value for this type (even though it's actually a string), will represent a dictionary in escaped JSON, and will be parsed on the client. The dictionary will have the following keys:

• selectCore: contains the actual SQL query. Do not include the "select" keyword as part of this, as that will automatically be preappended. If you wish to select specific columns, create and select from a subquery instead.

"data": {
    "feed": "",
    "function": "{\"selectCore\": \"from _entity_Account t\", \"tableAlias\": \"t\", \"containsWhere\": false, \"faultBlocks\": false, \"orderedBy\": \"accountName\", \"segmentedBy\": [], \"itemWhere\":\"\"} ",
    "functionId": "AllAccounts",
    "functionName": "Lists All Accounts",
    "functionType": "/Function/functionType[SQLiteQuery]",
    "itemType": "Account",
    "clientConfig": "",
    "functionParams": [
    ]
  }

Function Type: RDSQuery

Queries Against: Online Database

Fundamentally the same as SQLiteQuery except the queries go against the online database. This is necessary since not all items are entitled to the device. There may be situations however where you would still like to query the online database and see what items you're entitled against. In that case, you would have to write your query like this:

"data": {
    "feed": "",
    "function": "{\"selectCore\": \"from _entity_Account_read t where t.h_entitledUserId = '%?'\", \"tableAlias\": \"t\", \"containsWhere\": false, \"faultBlocks\": false, \"orderedBy\": \"accountName\", \"segmentedBy\": [], \"itemWhere\":\"\"} ",
    "functionId": "AllAccounts",
    "functionName": "Lists All Accounts",
    "functionType": "/Function/functionType[RDSQuery]",
    "itemType": "Account",
    "clientConfig": "",
    "functionParams": [
       'User.userId'
    ]
  }

Function Type: QueryAPI

Liquid Server supports hooking up against external web services, where that information is typically not stored. Real time services like this need to be configured separately in a configuration file. When it's time to invoke them from the client, you can call it like this:

 "data": {
    "feed": "",
    "function": "{\"functionId\": \"GetPricesForAccountAndProduct\",\"orderCol\": \"priceName\",\"postParams\": [{ \"accountId\": \"%?\", \"productId\": \"%?\", \"userId\": \"%?\"}]}",
    "functionId": "GetPricesForAccountAndProduct",
    "functionName": "Prices For Account And Product",
    "functionType": "/Function/functionType[QueryAPI]",
    "itemType": "Price",
    "clientConfig": "",
    "functionParams": [
      "Account.accountId",
      "CartLineItem.productId",
      "User.userId"
    ]
  }

The functionId inside the function dictionary must reference the web service referenced in the server configuration. The post parameters will get replaced using function params, just like any other function item.

Function Params

The iOS client offers a few things to help you reference the item later on.

• Context
  • Reference class is LDKContext. More information on this class can be found here. Any item placed in the context can be referenced with ITEMTYPE.FIELDNAME (e.g Account.accountId).
• FunctionManager
  • If the method in function manager returns a string, you may place the method signature as a function params. Function Manager methods also take in one parameter at most. You may invoke with:
    • now()
    • toShortDate(Account.expirationDate)