The Backendless Platform is built to run anywhere. We have had that vision right from the very first release of the product. Many of you are familiar with Backendless which we host in the cloud, however, exactly the same technology stack is also available as an on-premises solution, which we call Backendless Pro. With the release of version 5 of the product earlier this year, we tasked ourselves to rebuild how Backendless Pro is being distributed. Previously, it was available through a downloadable installer which led to difficulties in configuring and scaling the software. We decided to base the architecture on Docker where each component of the Backendless technology stack would be running as a separate Docker container. There are multiple benefits of this approach:
I am happy to report that the new Backendless Pro version 5 is now available. You are welcome to give it a try and run your own installation of Backendless Pro – the unlimited version of our platform(30 day eval licenses are automatically generated). You can find the instructions for installing and running the product on the GItHub page for Backendless Pro.
The following features are automatically included into the latest distribution:
This is Part 2 of a series of articles where you and I build a mobile app without any coding. The app we are working on is a ToDo app. In the previous post you did the following:
In this part of the series, you will implement the following:
Let’s get started (or technically continue, since we started in the previous post).
If you played or used Data Retrieval API in Backendless Cloud you may know that the server limits the number of objects retrieved from a table to 100 in a single call. For Managed Backendless and for Backendless Pro, this limit is configurable. In order to retrieve more than 100 objects, data paging is required. Paging greatly improves your application performance, but requires you to think how to architect your app in a certain way.
In this article I’ll describe how to get more than 100 objects, while using the minimum number of API calls, and do it without writing any code at all. Using this methodology, all that is needed to retrieve all objects from the database is a single call from the client application to the Backendless server.
Development of mobile applications generally requires two parts: the Backend and the Frontend. Of course, you could limit it only to the client-side, but if there is some data which must be stored on the server, there is no way to get around having a backend. In this series of articles, you will create a native mobile client-server application – a basic ToDo app. Backendless will take care of the backend, it gives you everything you might expecting from the server-side (user management, data persistence and scalability to name a few). And for the client side you will use the Dropsource service. In case if you are not familiar with this service, you can learn more about that from their website, but in short, it is an awesome service which lets you build native mobile apps without any coding. At the end of this series, your will have a native mobile application with the User Registration/Login screen, a screen with a listing of the ToDo items and a screen to create a new ToDo Item. Here’s a brief preview of the app along with real-time changes in the Backendless database:
In this article, I will describe how to use the Backendless API to save multiple related records with one primary (parent) record in a table. All related records (children) will be stored in separate tables as a part of the same routine.
Examples of this type of requirement might be personnel records tied to a single identifier (such as an employee number), or transportation manifests tied to a single record locator.