Working with Liquid Platform Kit—Composites, Functions and Query Filters

LPK (3) Blog Post 1.png

In my last tutorial I went through the LPKTutorialOne app, which explored the basics of CRUD with LPS. In this tutorial, we will go through LPKTutorialTwo, where we go through a configuration driven method of displaying data on the app, and the basics of filtering.

Reminder of the LPK examples git hub rep, where you can get all applications / code.

In LPKTutorialTwo, we will still be showing a list of movies in the main view controller, but implemented a little differently. Recall that in the previous tutorial, this was achieved with the following method:

Screen Shot 2018-06-25 at 1.47.00 PM.png

Not only that, but I separately queried for Movie and Rating and then put all of the data into iOS data structures. While I was demonstrating a point of abstraction in that tutorial, it is clearly suboptimal in the normal developer world. So how can we improve this query? Well the first answer, is Composite Schemas.

A schema in Liquid Platform simply defines an item. So naturally, we can create a schema to define a new item type, which is a combination of item types, and can be implemented with a SQL View. The composite schema in the community is called MovieRatingComposite. First, this schema extends the Movie schema. In the fields section, notice I only add the fields from the Rating schema. The other new line of syntax here is:

Screen Shot 2018-06-25 at 1.48.12 PM.png

There are actually two types of views you can define, a server and a client. For this tutorial I will only go through the client view. The following columns must be returned in your final data set:

  • h_type, h_id, h_clientId, h_processedAt

The rest of the SQL should is straight forward, where we are grabbing everything from the Movie schema, and doing a left join with Rating, so showing that information where possible.

So now, I have a new item type, called MovieRatingComposite. So there’s no need to do any of that funny NSDictionary manipulation. But we still have a couple of questions here:

  • How do I add complicated logic, other than just show all of one item type?
  • If the method above only returns an array of items, what about when I expect a large number of items?
  • How can I change what appears on the list without a new build?

The Liquid system has a solution for all of this, and that is Function items.

Function Items

The function item itself, is just like any regular item, synced down to the device. The definition for our function item in this tutorial is as follows:

Screen Shot 2018-06-25 at 1.49.51 PM.png

The function element is actually a JSON dictionary, with the selectCore being the main component of your SQL statement. In addition to this, itemType must be filled in correctly so that the system can return the correct items. If you want to find out more information about Functions, please click here.

Now the MovieViewController will display data based off a function item instead. Notice that at any time, you can change this query using Mission Control. In other words, you can control the logic of this query without having to give a new build.

Back to using LPK, we have to make a few modifications for this class. First since we’re using Function items, the result set is no longer an NSArray*, but instead, you’ll get back LDMSearchResults. This class has a separate delegate / set of methods you need to implement in order to update the UI properly.

Screen Shot 2018-06-25 at 1.50.55 PM.png

That’s it, you’re ready to try the app! But there’s a couple of fun freebees, just by implementing those new methods. Notice how in the app, the table is automatically sectioned by name. From an iOS standpoint, we only implemented an additional method for the list view, which is 100% standard, nothing else had to be done using LPK.

LPK (3) Blog Post 2.png

Also, since our function type is SQLiteQuery, you actually get pagination for free. This tutorial does not showcase this feature, but if you had a large number of movies ( > 10,000) this class would not have to change. (Feel free to create a new schema in this community that reads a large set of data) The result set will automatically bring up the first set of results, and as you scroll, more data will fetch automatically. When the UI needs to update, searchResultsDidAddNewRows will be called.

Query Filters (Searching)

Many of the fetch data methods offered by LPK will take in a query filter. This is a set of classes which generate the AND / OR clauses in a SQL statement. You’ll see in this tutorial, we only want to search by name and description, so only one clause is required.

Screen Shot 2018-06-25 at 1.51.56 PM.png

Once you generate your query filter, pass it into your corresponding LPK method, and everything will be taken for you. When using the app and searching for the word “Captain” , the query filter, in addition with our new composite schema will generate the following query (as shown in the logs):

Screen Shot 2018-06-25 at 1.52.07 PM.png

So now we’ve effectively re-created the Movie application, but now it is scalable, and configuration driven. The detail portion of the application has not changed, except since we have the composite item, after you tap on a row, I individually query for the two items in a separate query. Please feel free to contact me if you have any questions or concerns. In my text tutorial, I will go through some of the UI components / Gadgets that come as part of LPK.