In this article, we will show you how to write a service that will backup your application data with a time interval you specify. To do this, we will be using custom business logic, a timer, and the console SDK.
The result of this operation will be an archive with the data of all your tables (or, if you wish, you can modify the service for backing up specific individual tables, geo-points, application settings, etc.).
As you may have noticed in our release history, the EXTENDED STRING data type was removed almost a year ago. To be precise, it was more a merge of the STRING and EXTENDED STRING data than the removal of the latter. This means now you can safely use STRING data type for any kind of characters (including emoji! ????) without worrying if the column would support it. In addition, the sorting order for multiple non-Latin languages has been fixed automatically.
Relieving developers from the hassle of two string types has always been one of our main goals, and this is another small step in that direction. 
In this post, I’ll explain our reasoning for introducing the somewhat confusing EXTENDED STRING data type earlier and how we managed to finally solve the initial problem with no additional complication for the developers using our platform.
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.
In this article, we’ll talk about Backendless publish-subscribe messaging. One of the frequent questions we receive is: ‘How to get messages long after they are published.’ The default mechanism in Backendless keeps messages in the published channel for a short period of time only (around a minute). This becomes a problem if subscriber needs to have access to the messages after that time period has passed. This article describes an approach for storing published messages in Backendless database in order to keep published messages accessible even when they are no longer present in a messaging channel.
Publish-subscribe is a Backendless messaging pattern. The main idea here is to exchange data between a publisher* and subscriber** within a messaging channel***.
* publisher – a program using the Publishing API to send messages to a channel.
** subscriber – a program using the Subscription API to receive messages from a channel.
*** channel – a logical intermediary “transporting” the messages.
In order to keep messages accessible for an infinite period of time – you can save messages into the Backendless database right after they were published. To accomplish this, we’ll need to combine Data service API and the afterPublish event handler which can be added to the Business Logic tab of your Backendless application.
Once it’s added, just download the afterPublish handler code from ‘Download’ menu (you can select JavaScript or Java). Then open the generated project in any IDE and add the code to store published messages in a Backendless data table.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
@Asset( "chatRoom" ) public class DefaultChannelEventHandler extends com.backendless.servercode.extension.MessagingExtender { @Override public void afterPublish( RunnerContext context, Object message, PublishOptions publishOptions, DeliveryOptions deliveryOptions, ExecutionResult<MessageStatus> result ) throws Exception { String publisher = publishOptions.getPublisherId(); String messageData = message.toString(); HashMap savedMessage = new HashMap(); savedMessage.put("publisher", publisher); savedMessage.put("messageData", messageData); Backendless.Data.of("ChatHistory").save(savedMessage); } } |
Alternatively, the
afterPublish event handler can be added and deployed to cloud without any coding at all using Codeless business logic. Here are the steps of how it can be done:
1. Add new Codeless event handler 
2. When the handler is saved, Codeless designer will be opened. Add the following blocks to your Codeless logic. When done – click the ‘DEPLOY MODEL’ button.
Voila!
To avoid nulls, every message should be published with a not null value for publisherId :
|
1 2 3 4 5 6 7 |
public void publishMessage() { PublishOptions publishOptions = new PublishOptions(); publishOptions.setPublisherId("Jack"); String message = "Hello, this is my first message!"; Backendless.Messaging.publish("chatRoom", message, publishOptions); } |
For this scenario we’ll need to create a data table (Data > APP TABLES in your Backendless application) called ‘ChatHistory’ and define the following schema in it:
- Column publisher of type String
- Column messageData of type String
Once code for the handler is added, deploy the handler code to cloud using the following command in your IDE terminal:
./bin/Deploy.sh
Since the handler is deployed, every new message published to
chatRoom channel will be stored in a dedicated data table and will be accessible at any required moment by calling an API to retrieve data from a table:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public void retrieveMessageHistory() { DataQueryBuilder dataQuery = DataQueryBuilder.create(); dataQuery.setOffset(0); dataQuery.setPageSize(100); dataQuery.setSortBy("created"); Backendless.Data.of("ChatHistory").find(dataQuery, new AsyncCallback<List<Map>>() { @Override public void handleResponse(List<Map> response) { for (Map message:response) System.out.println("Publisher: " + message.get("publisher") + "\n" + "Message data: " + message.get("messageData") + "\n" + "Posted at " + message.get("created")+ "\n\n"); } @Override public void handleFault(BackendlessFault fault) { System.out.println("Error retrieving message History: " + fault.getMessage()); } }); } |
You will receive the following output:
|
1 2 3 4 5 6 7 8 9 10 11 |
Publisher: Jack Message data: Hello, this is my first message! Posted at Mon May 21 19:53:13 EEST 2018 Publisher: Jack Message data: And this is the second one Posted at Mon May 21 19:53:40 EEST 2018 Publisher: Mike Message data: Hi, Jack! Posted at Mon May 21 19:54:13 EEST 2018 |
If you’re starting an Android project with Backendless and import our SDK library from Maven, please pay attention to the version number of the library. We have published a beta version of the 4.0 SDK into Maven central. When referencing Backendless in Android Studio, version 4 is the default one to popup. Unless you’re building with Backendless version 4 (which will be the default backend in the Cloud very soon), make sure to reference version 3.0.25 of the library as shown in the screenshots below:
This is a question we get very often:
“how can I avoid rejected API calls when my app generates more calls than allowed by the plan’s limit?”
To give you the context of the question – all Backendless plans have a limit of API calls/minute. With the free plan the limit is 300, the Cloud 9 plan provides 600 and the Cloud 99 plan offers 1200 API calls/minute. With the Cloud9/99 plans, the limit can be increased by purchasing function packs which add 600 API calls/minute for each purchased pack. The backend monitors and enforces the limit for each minute, that is if you are on the free plan, Backendless will process the first 300 API calls for any given minute and all other calls above the limit during that minute will be rejected. When the volume of the incoming calls reaches 80%, 90% and 100% of the limit, the system will generate and send out an email informing you that a threshold has been reached.
To avoid rejected calls it is important to monitor performance of your app using Backendless console and stay on top of the notification emails. Backendless Console provides a chart of API calls/minute on the Manage > Analytics > Performance screen. The red line shows the current limit:
As you can see in the image above, the current limit for the app is 1800 API calls/minute and the app’s traffic stays right below the red line.
When you get a notification about the 80/90% threshold, we recommend analyzing the trend of the incoming calls and assessing whether the limit should be increased. It may be a one off occurrence of the traffic spike or a consistent growth of the volume of calls.
The backend for your Backendless app sends out emails for the following events:
- When a user creates an account for your app
- When a user requests password recovery
- When a user logs in for the first time
The default email address used by Backendless is develop@backendless.com, which is an automated account – we do not actively monitor incoming emails there. If you do not change the email address in your Backendless account and a user replies back to any of the emails listed above, the response goes back to the inbox for our automated account.
We see a lot of applications which are published to app stores where email address is not changed. As a result, you are missing direct communication received from your users. To avoid this, it is recommended to change the email address per the instructions in our documentation.
