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.
Applications use the Backendless API to access data, run searches, store, update and delete objects in the database. When a user authenticates himself with the backend, all subsequent API calls are executed on the behalf of the logged in user. However, if an API call is made without an authenticated user in the session, it is associated with an anonymous user. As a result, in an application that does not restrict data access, the data is exposed to everyone.
Restricting access for anonymous (non-authenticated) users is a very straight-forward process. Application developer has multiple options ranging from denying access globally for all API calls to restriction at the data table-level or even at the specific object level. In this article I review the process for restricting access globally.
In my previous post I described how to load complex data objects from the persistent storage using the “auto-load” technique. Using that approach a developer can statically identify specific (child) properties which should be returned along with the parent object(s) when a client app sends a request to load them. That approach works well for object relations which must be unconditionally returned with the parent object. However, there are many scenarios when the client app must control which relations should be preloaded and returned along with the parent. The API described below allows to accomplish that.