Backendless file storage includes a very powerful (and quite convenient) integration with git. There are many features which come with that integration and I will be describing them in detail in future posts. Here’s a brief list of what you can do with it:
Previously I wrote how to save in Backendless data objects with related geopoint(s). The data-to-geo relations are bidirectional. It means just like a data object may reference a geopoint (or more than one) as a relation, a geopoint may reference a data object or a collection of in its metadata. Consider the example below. The code saves a geopoint which represents the Eiffel Tower. The geopoint references a data object which represents the tower’s main engineer Gustavo Eiffel saved in the Architect table. Notice the “gustavoEiffel” object is a plain Java object (a POJO) which is saved in the Data Service storage in backendless. The relation between the geopoint and the data object is handled through the geopoint’s metadata:
In one of my previous articles I have reviewed how to register app users with the API. By default a Backendless backend declares a user entity with three properties: email, password and name. The “email” property is configured as identity by default, meaning its value should be passed into the login API request.
Typically user entity properties correspond to the fields in the app’s user registration form. When a user registers with the app, the data from the registration form is sent to the server using the User Registration API. While processing a user registration request, Backendless extracts information from the incoming user object and if it contains a new (undeclared on the backend) property, the property is added to the user entity schema. Consider the following sample code:
This is a brand new feature from the release we just announced and it is a powerful one I think the potential of mapping a location to a data object can lead to a lot of interesting opportunities. For example, consider a taxi booking service like Uber. You may have multiple cars/drivers available for hire as well as customers putting pickup requests. Both drivers and customers may be represented by corresponding data objects and locations on the map.
Consider the following example:
I am very happy to report that we released a new version of Backendless. The new release is tagged as version 1.9.0, which is a new numbering scheme for us – we used to label releases with names attached to various events.
The new release is packed with features, improvements and bug fixes. I’d like to review the most significant ones and will be writing more in detail about each in my feature-a-day blog series.
The Backendless console is a development tool which is also the front-end for one’s backend. It is quite often when more than one developer may need to access the console to view data, try queries or adjust the security settings. The console and the backend are built in a way where concurrent developer logins to console are not supported. As a result, when more than one developer try logging in to console from different computers, the later login will log out any earlier one. In order to accommodate the scenario of the console supporting multiple developers logging in and sharing the same backend, we introduced the development team concept. The primary developer (the one who created the application) can invite other developers to the application. An invited developer receives an invitation email with a link to join the development team. If the developer already has a Backendless account, they will automatically join the development team by clicking the link in the email. Otherwise, if they do not have an account, they will be required to register with Backendless.
To invite a developer to your development team:
The owner of the application can control the permissions assigned to other members of the development team by clicking the icons at the intersection of the developer name and individual operations.
Sending an email is a very common operation for many applications. For most of them it is the server-side that is responsible for delivering an email message. Backendless makes it trivially easy to deliver a branded email (meaning it will look like it was sent by your app) in the plain text or HTML formats (or both). Consider the following code which sends an HTML-formatted email message:
Backendless File storage can be used to host web applications. The file storage includes a special directory – “/web” which is used to host web application content. Since the default URLs for files in your file storage are rather long and use the backendless.com domain, it may be desirable to map a custom domain name to your Backendless backend and specifically the file storage. Note that at the time of writing of this post, this feature is available for the applications in the Backendless Plus pricing plan, but that may change in the future.
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.