Message:

Subscribe rss
Blog categories

Previously I described how to use the Backendless Console to generate custom business logic code. In this post I will describe one of the most amazing features in Backendless – an ability to debug custom server-side code on the developer computer before deploying it to the cloud. It would be very helpful for you to go through the previous feature to establish the surrounding context.

Once the code is generated, you can use the Download button to get a project archive (zip) with all the source code. In addition to the code the archive also contains a special command line utility which you can use to run the custom code locally. The trick of the local execution is the code inject itself into the API processing chain. This happens despite the fact that the API invocation is handled in the cloud, but the custom code runs on your computer. To put things in perspective, see the diagram below:backendless incocation chain - Feature 116: Local debugging of custom business logic using CodeRunner

Continue reading

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:
backendless incocation chain - Feature 114: Custom Business Logic - Event Handlers (Overview)

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:
intellij debug setup2 - Feature 112: Local debugging of Backendless Timers on a developer machine

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:
cbl codegen - Feature 111: CodeRunner - Custom Business Logic Utility

The downloaded file is a ZIP archive of the project. The contents of the archive would have the same structure as shown below:
project structure - Feature 111: CodeRunner - Custom Business Logic Utility

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:
    creating timer - Feature 110: Creating custom business logic timer with console
    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