There is an API for loading the very first object created in the table. The first object is determined by the value in the created column – Backendless picks the one with the smallest timestamp. The code below demonstrating loading an object from the Person table:
As data objects are being saved or updated with the API requests some properties of the objects may not have a value assigned to them. It may be necessary that for those properties a default value is assigned. This is identical to how relational databases may have a default value for a column.
Configuring a default value for a column is very easy. You can set it when you declare a column or after a column is already created.
Alternatively, when a column already exists in a table schema, there is a field which displays and lets you edit the default value:
Once a default value is assigned to a column, it becomes immediately effective. When an object is saved or updated does not have a value for a property corresponding to the column, Backendless inserts the default value.
Backendless provides an easy to use API to introspect data tables. Given a table name, the API provides information about table columns, their names, data types, default values, etc. If a column represents a relationship, it is properly denoted as such in the provided information.
The logout API is a logical counterpart for the User Login API. The logout step is not required for most apps – user session will expire automatically. However, some apps provide the functionality, especially those with a special multiple login policy. The logout API is very simple – a single line of code terminates the current session:
In my previous post I described how to adjust object’s access control list (ACL) using Backendless console. As I mentioned, in addition to console, object’s permissions can be controlled using API. In fact, for any persisted object, Backendless supports the following capabilities:
granting/rejecting permission to execute find/save/update/delete operation on an object to:
The general API usage pattern is:
DataPermission.<OPERATON>.grantForUser( userObjectId, dataObject )
DataPermission.<OPERATON>.denyForAllRoles( dataObject )
Every data objects saved in Backendless has its own access control list (ACL). Object’s ACL includes permissions for users and roles for all Data service operations. Using ACL an application may be configured to allow users (and/or roles they belong to) to be able to execute Data Service API calls. For example, in a shopping app you may have the Customer and SupportRep roles. Users in the Customer role may have the permission to create and update objects in the Incident table, but may not delete them. A user in the SupportRep role may have the permission to delete those objects.
Object ACL configuration can be done via API or Backendless console. This post review the latter. To get to the ACL screen for a specific object:
Previously I wrote about how to store and retrieve objects to and from server-side in-memory cache. Quite often when working with cache, it is required to check if an object already exists in cache. Backendless provides an API for that function. The code below checks if an object exists in cache, if not, it places it in there and then runs the existence check again:
This may apply only to some apps, especially if your license agreement explicitly prohibits users from specific countries, or if perhaps you want to allow users only from a specific country. The feature lets you select the countries where users would not be allowed to consume the backend of your app. The feature relies on geo-decoding user’s IP address and we do our best to maintain the mapping between the IP addresses and the countries they are assigned to. If a country is selected as one where the APIs for your app should not be allowed, then any request a user from that country makes would be rejected. To configure geography-based restrictions:
Previously I wrote about enabling email address confirmation for the app users after they register and before the login. The feature sends out an email with a link a user must click in order to confirm his/her email address. The text of the email can be easily customized:
Once a user of a Backendless-powered app logs in, a session is established. The session has an inactivity timeout that is reset with every new API call made within the session. The default timeout value is 3600 seconds (1 hour). It means Backendless will keep a session alive 1 hour after the most recent API request. The inactivity timeout value is configurable in Backendless console:
The Enable Session Timeout configuration is located under Users > Login. The default setting if the configuration property is OFF. In that case, the inactivity timeout is set to 3600 as described above. To change the setting, enter a timeout value in the inactivity timeout textbox and click the toggle to set it to the ON state. The maximum allowed value is 30 days, which is 2592000 seconds.