Monthly Archives

Backendless Push Notifications are getting a much-needed facelift. Today, with the release of version 4.3.0 you will start noticing some improvements. Specifically, you will see the  DeviceRegistration data table:

Backendless supports two approaches for saving data objects in the database: class-based approach and map/dictionary approach. With the class approach, you declare a class, instances of which represent individual objects stored in the database. With the introduction of Swift 4, it is important to add a new attribute to your Swift 4 classes. For example:

Notice the @objcMembers  attribute declaration in the class. The attribute allows Backendless SDK (which is written in Objective-C) to access object’s property values. If you do not add the attribute, objects retrieved from the server will not have properties initialized with the values.

It is also possible to set a project-wide configuration property. When you do that, you do not need to add @objcMembers  attribute, however, you will see warnings when the project is built. To set the project property, open “Build Settings” for the project target, locate “Swift 3 @objc inference” and set it to “On”.

For additional information on the @objcMembers attribute, see the “inheriting from Objective-C Classes” section in the Swift 4 programming guide.

Data retrieval in Backendless has gotten significantly more powerful with the release of version 4.2.0. We added support for subquery into the syntax of whereClause . The improvement allows your apps to run two queries in the context of one request. The first query identifies a set of objects which is fed into the second query. Consider the following data schema:

Suppose your app needs to get all blog posts where the person who posted a comment has a specific email address (say @backendless.com ). Using subqueries, it can be done with the following whereClause sent to the BlogPost table:

Let’s review how this whereClause is processed by Backendless:

1. Backendless detects that the query at the top level uses the in()  operator.
2. It checks if the contents of the  in()  operator have the format of a subquery and if so, evaluates it accordingly.
3. The subquery contains an “internal whereClause”, which is:
   author.email LIKE '%@backendless.com'
   The internal whereClause is applied to the objects in the Comment table.
4. For all found  Comment objects, Backendless gets a list of values for the blogPost.objectId column.
5. The resulting set is fed into the  in()  operator which fetches the final set of objects from the  BlogPost table.

General SubQuery Syntax

The general syntax for subqueries is:

How it works:

1. If internalWhereClause  is present, it is executed in the table identified by TableName.
2. In the resulting set of records, values must be selected for the column identified by columnOrRelatedColumnName.optionalColumnName.
3. If internalWhereClause is not present, the contents of the IN operator have the following syntax. It represents the entire set of values identified by the specified column: TableName.columnOrRelatedColumnName.optionalColumnName 
4. The resulting set of values is used in the  IN operator, thus the final query ends up being:
   searchColumnOrRelatedColumnName IN ( value1, value2,, valueN ) 

Additional Examples

Consider the following data schema:

1. Get all OrderItem  objects for a customer from New York :
   objectId in (Order[customer.address = 'New York'].items.objectId)
2. Get all Customer  objects who spent more than 1.99 on an item:
   objectId in (Order[items.itemPrice > 1.99].customer.objectId )

Please let us know if you can think of additional examples you would like us to demonstrate.

Enjoy!