When analyzing data, you may need to know the average salary of all employees, the quantity of goods in stock, the number of individual items in stock, the maximum or minimum cost, and so on. These tasks are easily handled with aggregate functions. Aggregate functions perform calculations using the values in a column in order to obtain a single resulting value.
Backendless supports several aggregate functions, such as:
- AVERAGE – to calculate the average
- COUNT – to calculate the number of rows in the query
- SUM – to calculate the sum of values
- MIN – to calculate the smallest value
- MAX – to calculate the largest value
Let’s take a closer look at how to work with aggregate functions using Backendless. In this article we will look at using aggregate functions with Backendless REST API, but we also show how to work with aggregate functions using Backendless SDK for iOS API, Backendless SDK for Android/Java API, Backendless SDK for .NET API, and Backendless SDK for JavaScript.
For this series, we are developing an iOS game called “TapMe”. As TapMe is a multiplayer game, it provides registration for the new users and login for the existing ones. In this article, we are going to demonstrate how to handle user registration and login, as well as how to store a player’s information in the database.
The source code for the game is available in the author’s personal Github repo: https://github.com/olgadanylova/TapMe.git
You can read Part 1 of this series here.
Some Backendless users choose to use REST APIs in their JavaScript projects. While many can simply use our pre-packaged JS-SDK, that SDK may not always be able to achieve the result the user is seeking. Today we’re going to show you how to build a custom and very light API client library for working with Backendless API. Some time ago, we created a simple NPM module named “backendless-request” for sending CRUD requests to the server. That package is used in all our services such as DevConsole, JSCodeRunner, JS-SDK, etc.. If you would like to see the sources of the package, you can find it on Github.
It is common for developers to build apps where users will have varying access to data and elements within the app based on the user’s role. Being able to limit user access is important to data security, user management, and often, the financial success of the application as user access is commonly tied to how much the user pays. In this article, we are going to show you how you can hide some object properties based on the user’s role. To accomplish this, we will be using Event Handlers.
An event handler is custom, server-side code that responds to an API event. For every API call, Backendless generates two types of events – “before” and “after”. The “before” event is fired before the default logic of the API implementation is executed and the “after” event is triggered right after the default API implementation logic. An event handler can respond to either one of these events. A synchronous (blocking) event handler participates in the API invocation chain and can modify the objects in the chain’s flow. For example, the “before” event handlers can modify arguments of the API calls, so the default logic gets the modified objects. Similarly, an “after” handler can modify the return value (or exception) so the client application that made the API request receives the modified value. For more about Event Handlers, you can read the documentation.
By the end of this guide, you will have a Backendless application with a custom API event handler that modifies objects received from a table and removes restricted properties based on the user’s role.
It is very easy to use Backendless with Xamarin, Microsoft’s open source native app builder. You can try out Xamarin for building apps for free with the Community edition of Visual Studio from Microsoft. In this post, we’re going to create a simple example based on the Xamarin ToDo list sample provided by Xamarin.
One of the most powerful features that Backendless 5 has available is the capability for you to implement your own License Manager for creating and checking licenses for your product/customers. In this article, we will touch on some Backendless services such as data management and Business Logic and we will use one of the Backendless Client SDKs.
In one of my previous articles, I showed how to develop a custom Alexa skill using an example of a Trip Planner app (How To Build A Dialogue Custom Alexa Skill Using JavaScript (Without Lambda). In this article I will show you a more complex example of the interaction between Alexa and the user. Today will build a “Guess My Number” game where Alexa (or technically the skill) thinks of a number and the user tries to guess it while the skills suggests whether it is lower or higher. Here’s a sample dialogue a user may have with Alexa once you implement the skill:
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.
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.
What does “mobile-to-web cross login with a QR code” mean ? It is one of the approaches for the two-factor authentication. Suppose that a user is already authenticated in your application (in my example it would be an android app) and the user wants to use it’s actual session to perform an automatic authentication in another application (in my case it’s a web app). There are several examples of popular apps which use this approach. For example, to login into a web session with WhatsАpp, you must login on your phone and then scan a QR code in the web interface.
