Backendless Blog

Subscribe rss
Blog categories

Video broadcasting and streaming is one of the coolest features of Backendless. Our Media Service API enables client-server functionality for working with live and on-demand audio and video content. A mobile application which uses the Media Service API can broadcast audio and video from the device’s cameras and microphone. Backendless automatically handles streaming of the received media content to other clients or recording of the content on the server. The API can also support the capability to stream a pre-recorded (on-demand) content managed by the Media Service. More details about these features are available in the Media Service documentation.

This post describes how to build an iOS application using the Swift language. The app will record a video on the server and then subsequently play it back.

Continue reading

In my previous post I introduced the feature of server-side API event handlers – a mechanism for injecting custom business logic into Backendless. In this post I am going to review the process of creating an event handler for User Service APIs using Backendless console. The User Service APIs include: user registration, login, logout, user update, password recovery and retrieval of user schema (a list of user properties and their types). You can build an event handler (or two event handlers – “before” and “after”) for each of these operations.

Continue reading

There are two types of custom (server-side) business logic supported by Backendless – timers and event handlers. In my previous posts have reviewed the entire process of developing, testing and deploying timers. Now I’m going to focus on event handlers. An event handler is a piece of custom server-side logic which can be plugged into the API processing chain. The diagram below illustrates how API processing works – the gray box is the server-side of Backendless. As you can see, there are two blocks where custom business logic can be placed – the “before” and “after” handlers:

Continue reading

Now that you know how to generate code for custom business logic timers (Backendless background jobs) and how to locally debug custom business logic, it is time to learn how to deploy that code to production. By “production” I mean the Backendless Online service running in the cloud. It may not be your ultimate production phase – you may still be developing the application, but it is a convenient way to distinguish it from the debugging/development step.

In order to push your custom server-side code with Timers to Backendless, the CodeRunner distribution and the zip file downloaded from the Business Logic code generator, include a command line utility. The utility name is “Deploy” and it has an appropriate extension for the supported operating systems (.sh for Linux and .bat for Windows).

Continue reading

In my previous post I introduced Backendless CodeRunner – a debugging utility for custom business logic. Now that you can run your timer code locally using CodeRunner, I’d like to show how you can attach your IDE to the CodeRunner process and debug the code.

The CodeRunner is configured to listen for remote debugging connections on port 5005. It is sufficient to create a debugging configuration in your IDE. For example, in IntelliJ IDEA, the configuration would look like this:

Continue reading

In my previous post I described how to use custom business logic code generator to create Backendless timer code. The previous post left off at the step when the Backendless Console created the code. To download the project files with the source code click the Download button:

The downloaded file is a ZIP archive of the project. The contents of the archive would have the same structure as shown below:

There is a project file for IntelliJ IDEA, however if you use Eclipse, it is very easy to import the project in it as well. Open the project and you should be able to compile it without any changes. The code straight out of the code generator does not have any custom business logic –  it is a wrapper required by the Backendless framework. To add custom business logic open the timer class, it will be in the hierarchy of the /src directory. I have added custom code which stores an object in Backendless Data Store every time the timer runs:

Now that I have a Backendless Timer with custom code in it, the question is how to run it. Obviously the code can be deployed to the Backendless cloud, however, wouldn’t it be nice to be able to run it locally first for testing and debugging purposes? The answer is ‘yes’! This is exactly what Backendless CodeRunner for Java does. The best part is CodeRunner is already included into the ZIP file generated by Backendless Console (the file downloaded at the beginning of the post).

If you use IntelliJ IDEA, the project is automatically configured to compile the code into the /classes directory shown in the screenshot above. The directory is special – this is where CodeRunner looks for custom code classes.

To run CodeRunner, open a command prompt window and change the current directory to /bin (see it in the screenshot above). Run CodeRunner using the scripts in the /bin directory. For example on a Linux system, run the following:

You should see the following output:

CodeRunner automatically inspects the compiled code, determines that is has one timer and registers it with the Backendless ‘mothership’.

In the future posts I will be describing the process for debugging the timer code on the developer machine and deploying custom code to Backendless.


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

Continue reading

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.

Continue reading

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:

Continue reading