Monthly Archives

In my previous post I wrote about Backendless server-side timers – blocks of code which run on – pre-defined schedule. A timer is a Java class and can be created by hand. The most tedious part is figuring out the scheduling definition. Currently it is done by declaring the timer’s schedule through a JSON object in the class’ annotation. Backendless console significantly simplifies this process through a built-in code generator. To create a timer:

1. Login to Backendless console, select your app and click the Business Logic icon.
2. Click Timers in the menu on the left.
3. Click the Add Timer button:
   
   Continue reading

Great news! We’re featured in DZone’s latest research guide, the Guide to Cloud Development, 2015 Edition.This guide features key findings from a survey of 600 + IT experts exploring the issues of Cloud Development, Global Cloud Trends – 2015 as well as offers a solution directory of the leaders in cloud development.

Strong Adoption in Testing, Deployment, and Production Environments

One of DZone’s central findings is the growth of Testing/QA and Production/Deployment environments in the cloud. They found that 55% of respondents are performing

There are two types of custom business logic scrips supported by Backendless – API event handlers and timers. In this post I will review the latter. A timer is a server-side program deployed to the Backendless server infrastructure which is scheduled to run on a pre-defined schedule. Once the code is deployed, Backendless makes sure the code runs exactly accordingly to the schedule. We handle all the runtime aspects – finding an available host to run the code, loading all the dependencies, making sure the code runs securely within an isolated sandbox. Backendless supports a variety of schedules. A timer may be scheduled to run only once, or once a day at the specified time, every day, a few times a week, a month, a year, etc. Additionally, a timer may have an expiration date/time.

Previously I wrote about the API to send a temporary password to a user (restore password). With the free plan the API sends a password generated by the backend system. However, with a paid plan, the same API works differently. Rather than sending a computer-generated password, user receives in an email a link to a customizable page where they can choose their own password. The webpage which Backendless uses by default is loaded from the file storage allocated to your Backendless backend. You can see it at the /web/templates/change_password/ directory:

In my previous post I described how to send a temporary password to a user when he cannot login. A password is delivered in an email message. The message can be customized using Backendless console:

1. Login to Backendless console, select your app and click the Users icon.
2. Click the Email Templates menu.
3. Select User requests password recovery from the drop-down menu.
4. Modify the email template text using the built-in editor.
5. You can preview the email using the Preview button. When you are done save the email template using the Save button.

Previously I wrote about changing user’s password by administrator or via API if user can login. There is also a scenario when a user needs to change password when he cannot login for the reason that the password is forgotten. In this case, Backendless provides a simple API that delivers a temporary password to the user’s email address. The email message can be customized by editing the template for the ‘restore password’ event. This behavior is specific to the apps on the free plan. Applications on the Backendless Plus or above plans provide more flexibility for resetting user’s password.

This is an introductory post for a very broad feature – injecting custom server-side logic into Backendless. There are a lot of smaller features in Custom Business Logic, but it’s worth to start with a general overview. As you have seen in the previous posts, services includes in Backendless execute specific and well-defined operation based on the received arguments. For example, the logic API request checks if the user credentials are valid and if they are, establishes a session. An API call to search for an object in a data table, finds the object and returns it back to the client. There are many scenarios when the built-in functionality either should be augmented to perform some additional logic or completely overridden. This is exactly what Custom Business Logic (CBL) does – it is a framework that lets you inject your own code into the Backendless API invocation chain.

CBL relies on the concept of event handlers, where an event is an API invocation request. For example, the Login API request is the Login event. For every event, there are two possible handlers: a “before” and “after” handler. These handlers is where your custom code can be injected. The following diagram demonstrates the API invocation chain:

When a user registers or update his account, application uses the user registration API. It is common for the user interface to enforce the data entry rules and validate the values entered by the user. However, an alternative approach is to perform data validation on the server. Backendless supports user properties validation on creating and updating user objects using regular expressions. Backendless console includes several pre-configured regular expressions for the most common data types, such as email address, URL, social security number and US phone number. Additionally, app developer can specify their own regex. To configure a validator for a user property:

In my previous posts I described how a data object may have a related geopoint (or a collection of). One of the benefits of the data-to-geo relationships is search by distance. That means Backendless can search for data objects using the location of the related geopoints. Consider an example from a taxi-reservation system. There may be several cabs-for-hire in the area. Your app needs to locate all available cars within the specified distance from where the customer is located.

The class representing a cab may look like this:

Previously I wrote how to upload files to the Backendless Hosting system. Once a file is uploaded, it gets a public URL which can either be obtained using Backendless console or calculated using the following template:

Alternatively, when a file is uploaded, the API call returns the URL of the uploaded file. The sample code below demonstrates how to download the file. The code prints out the contents of the file to system console, but it can be easily modified to store it in the local file system, or transfer elsewhere over the network, etc: