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.
Previously I wrote a post on how to retrieve data objects from Backendless. The code in the article loads a collection of the Restaurant objects and although it does not show it, the related collection of the Location objects arrives un-initialized. That is the default behavior of Backendless when it comes to loading related objects. The code below demonstrates that the collection is indeed empty (null). (The code in these examples is from the article describing how to generate client-side code based on data tables).
In a Backendless backend you can restrict access to API operations and/or application data. A restriction may apply either to specific users or to roles. When a restriction applies to a role, it automatically applies to the users in that role. For example, suppose you have two roles in a job-searching application – employer and job-candidate. Each role will have a certain set of permissions, for instance an employer can see all the candidates who applied for a job.
Backendless supports two types of roles – system-defined and developer-defined roles. System roles automatically come with the backend, Backendless assigns them based on how user logs in or accesses the app. For example, the AuthenticatedUser role is assigned to any users who successfully logs in.
It is a common use case when two or more users try (or need) to login to an application using the same user ID and password combination. Some applications allow it (for example, Netflix supports concurrent logins with the same credentials from different devices) and other apps restrict it. With Backendless you can easily configure your backend to support either way of handling multiple logins without writing a single line of code. To configure the multiple login policy:
Since today is a saturday let’s review a fun feature – ROI (return on investment) calculator. That many sound like a boring subject, but we sure tried to make it fun. Indeed, if you are a developer and are tasked to figure out how a product or a service can save money, it may be a daunting task. Certainly not with Backendless. First of all you can start with our service at no cost all – the Backendless free plan is very generous with unlimited API calls and no request per second throttling. On top of this, Backendless will tell you how much money you’re saving just by using it. Here’s how you can find out:
Loading data objects from the Backendless persistent storage is a fundamental operation a large majority of the online/mobile applications require. Backendless data retrieval API is simple, yet very powerful. As you will learn in the course of this series, the API provides the following capabilities:
In this post we continue our mission to build a restaurant to-go order app. So far we have put together UI mockups for the future Backendless application, and designed data schema for all application’s data entities. At this point we got very close to the coding part. As the title of this article suggests, we will be generating some code, but before we do it, let me describe a core principle of the client-server integration with Backendless.