Subscribe rss
Blog categories

In my previous posts I described how to set up a sample Geolocation data set and how to retrieve geopoints using the API. The geopoints in your application would not be the ones from the sample data set, we used it only to make it easier to get started with Backendless Geo location. Adding geopoints to your Backendless backend can be done either with the API or by using data import. In this post I will review the first approach – saving geopoints with API.

Continue reading
There are several way to upload file content to the server:
  1. A traditional approach where a physical file from the client environment is uploaded using the API.
  2. Creating a remote file with content generated on the client side.
In this article I will review the first option – uploading a file with the API.
Once a file is uploaded, the File Service enables the following:
  • You can see the file in File Browser in Backendless console.
  • File can be downloaded via a URL assigned to it. The URL is composed as:
  • Application developer can assign permissions to control who (users or roles) can download or delete the file.
  • If git integration is enabled for the application, the file is also committed to the repository.
    Continue reading
Every Backendless backend includes a file storage space which can be used by your application or can host your web application. The space is managed by the Backendless File Service which is a core element of the Backendless Platform. The service provides APIs for file upload/download and deletion, manages files/directories permissions and handles git integration. Backendless console includes a powerful visual tool for file storage management – File Browser conveniently available behind the Files icon.
Continue reading

As you develop application, the backend accumulates a lot of development-related data. This data may include test objects in your data tables, random user accounts you used to see how logins work, meaningless geopoints or files. Sometimes you just wish you could delete all the data, but keep the data structures (tables, file directories, geocategories). Backendless provides a way to do just that by the means of Application Reset.

To reset the backend for your app:

Continue reading

Posted in Feature-a-Day

Previously I wrote an about how to load object relations using the auto-load and the one-step approaches. Both of these approaches return a complex hierarchy of data where the parent object includes child entities at the time when it is retrieved from the server. Quite often these approaches are less than desirable for the reason that they may result in large payloads of data which may slow down data transfer and result in substandard user experience. Additionally, an entity stored in the Backendless backend may have a lot of related properties and it may be desirable to fetch a specific relation after the parent object has been loaded by the client. To enable loading of relations after the client retrieved the parent object, Backendless provides API to load related objects with a two-step approach. The “two-step” term describes the fact that the parent entity is loaded with the first call and the second call/step is to fetch specific relations. The sample code below demonstrates retrieval of the “locations” property for the Restaurant objects. This example is based on the Restaurant-to-Go application schema.

Continue reading

In one of my previous posts I described how to restrict access to all data for “guest” users. The Backendless security model lets you control access to data tables, or more generally “asset containers”, at the role and operation levels. That means an application developer can set up security restrictions for API operations on a specific data table for a security role. For example, a job/resume search application may have two application roles: Employer and JobSeeker. Suppose there is a table called JobListing which contains job listing objects submitted by the users in the Employer role. Actions permitted on the table for the JobSeeker role may look like these:

Continue reading

In one of my previous posts I wrote how to run SQL searches against your mBaaS backend data. The SQL queries you run in console can be used verbatim in your mobile and desktop applications built with Backendless whenever you need to run a search for the app data. We refer to the SQL queries supported by Backendless as the “where clause” since it must contain the WHERE part of an SQL statement.

When a REST client runs a data search, the SQL query is a parameter in the request URI. As a result, it must be a URL-encoded value. To make it easy for developers to get an encoded value, Backendless console provides a way to encode SQL queries. For instance, using the Restaurant-to-Go app I’ve been using in this series, the following where clause runs a search for all restaurants with the name which includes the word “Cantina” and located in Frisco:

Continue reading

We have been hard at work on the new release. It has a combination of new features, improvements and bug fixes. A formal announcement will be posted as soon as the release becomes available, but in the meantime if you have an application you would like to try with the new build, please let us know. You can contact us on our Facebook page, Twitter account, support forum or the website.

Posted in Status

In my previous post I gave a brief description of the Backendless Geolocation service and wrote how to setup sample geodata. Now that we have a collection of geopoints, let’s look into the API to retrieve these points. Similar to data objects, Backendless returns geopoints using paged data. Consider the following sample code:

Continue reading

This is my first post on geolocation – one of the most powerful features of Backendless. The geo location service provides APIs for storing, searching and managing geolocation data. There are three main elements which the geolocation service operates on: geocategories, geopoints and points metadata. A geopoint contains a pair of coordinates: latitude and longitude. Additionally, a geopoint may contain metadata – an arbitrary collection of key/value properties. Finally, an application may group points in a category logically or otherwise. For example, the “Restaurants” category may contain geopoints representing various restaurants in a geographic area. Every geopoint could have the metadata properties such as “atmosphere”, “cuisine” with the values describing the atmosphere at the restaurant and the type of food served.

Continue reading