Today, we are going to look at a useful and interesting, but hidden, feature of Backendless. Some features like these are not covered in the documentation, so they are not recommended for use in production because they are not supported and there is no guarantee that their implementation will not change. Still, these features can be very helpful during initial development. Using these features is not for the faint of heart!
This post will show you how to implement a kind of “expiration” for your data objects. The strategy is sufficiently abstract, so it’s applicable to any resource you need to expire, including files, logs, and so on.
Since the database does not have any built-in expiration mechanism, we’ll have to implement it on our own. Fortunately, the task is pretty easy because we have access to Backendless Business Logic. The idea is to create a Timer, which is going to run with some fixed time period and delete the resources based on your criteria.
In this article we are going to demonstrate how to create a simple chat application with the new Backendless SDK for Flutter. This will give you an overview of the process needed to integrate your Backendless server-side with your Flutter app client-side. The Backendless SDK for Flutter is currently available for Android and coming soon for iOS.
One of the final steps before you release an app is to setup proper security. Specifically, the security of your File Storage is perhaps the most important since it may contain your business logic code, your public website data, your logs, and any other assets which you probably do not want anyone from the outside to be able to see. This post will provide a few guidelines on how to structure your File Storage with security in mind and instructions on how to set up the permissions properly. The sample use-case will be a bit over-concerned with security, so you most likely won’t need all of this for your specific case, but you’ll be aware of what to do in the worst case.
If you’ve worked with Backendless API for a while, you may occasionally run into a situation where the functionality you’d like to have isn’t readily available. One such function is the programmatic management of your application’s data tables. For instance, you may need to clear up all the data and recreate the table structure with specific columns on demand while developing your app. This article will show you how to do that and more.
The ability to send push notifications has been a key Backendless feature for quite a while, but until now, it only had a basic set of actions such as sending to all devices in a specific channel and/or to a specific device type (Android/iOS). With the last changes it has grown into a powerful tool with a bunch of very flexible and convenient functionality. Now you can:
In this article, we’re going to review the first two points and in the next article the last two.
Today we are going to talk about a very valuable feature available for Managed Backendless and Backendless PRO users called Low Priority Tasks. In this article, we’ll look at how it works and what is it best used for.
Backendless custom business logic (custom event handlers and custom API services) tasks are put into a single queue and executed by a dedicated service called CodeRunner. In Backendless Cloud, these tasks do not have any kind of priority and are executed according to the task’s position in the queue. But there are cases when the CodeRunner queue is spammed with “heavy” requests which take 10 or even 20 seconds to execute, i.e. getting hundreds or even thousands of records with multiple relations, utility requests to delete thousands outdated records in a table, etc.
Today we are going to demonstrate how to create a simple event handler to track subscriber statistics on your various messaging channels. This gives you the ability to easily track the number of subscribers for each of your channels to help you manage channel load and gauge user interest in specific topics. Used in combination with API usage tracking, you will have a great sense of what your users are doing within your app.
To start, we will create a new application and call it Messaging_Statistics.
This is the final article in a three-part series on building a multi-user iOS game app. In part 2 of this series, we demonstrated the process of player registration, login, and storing in Backendless Database. Now, let’s take a look at counting the score for every player, creating a leaderboard, and how all of the game installations are notified when this information changes.
In this article, we are going to continue developing our ReactJS web application using Backendless for the backend. This is part 4 of our series, so be sure you’ve read through parts 1-3, linked below:
If you have already read those then read on. Otherwise, we recommend you either read read all of the previous articles and build the app step-by-step, or you can clone the app from this github repository and use this commit as a starting point. Today we will build our app for the first time and deploy it to Backendless Files.