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.
https://api.backendless.com/<application id>/<version name>/files/<path>/<file name>
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:
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.
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:
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:
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.
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:
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.