As application is progressing through its lifecycle, there are different teams involved in interacting with the app and its backend. These teams include developers, testers, security auditors, system administrators ultimately customers and the users of the app.
Traditionally, application goes through the stages of development, testing, staging and production. Each stage has its own group of users. It is important that each stage has its backend with all the data, security policies and business processes in an isolated from other stages environment. Backendless provides support for multiple app environments through a feature called Versioning.
One of the hidden gems packed with features is Backendless REST Console. It is a part of Backendless console and is located in its own tab on the Data screen. The console does exactly what it sounds like – lets you run REST requests against your data tables. Let’s review how fetching your data (AKA running HTTP GET requests) works in REST Console:
In my previous post I reviewed the user registration API. Now that you know how to use the registration API and have a registered user, the next step is to review the login functionality. The video below focuses on the apps’ login screen and the Backendless Login API.
In the previous post I described how to obtain file’s public URL using the Backendless developer console. Even though one may obtain a public URL for a file or directory, it is very easy to change the permissions to restrict file download for anonymous (not authenticated) users. To restrict access:
Any file in the Backendless File storage is also accessible through a public URL. This functionality can be restricted by changing security settings. Public file URL can be built using the following format:
https://api.backendless.com/<application id>/<version name>/files/<path>/<file name>
In the video below I review the code for the User Registration screen of the RestaurantToGo sample app. Additionally, I discuss the usage of the Backendless Registration API. In the previous post and video, I reviewed the process of setting up the development environment for the application.
This is the first post in the series documenting a sample Android app we built to demonstrate various Backendless features. (You can read/watch project overview posted earlier) The video below demonstrates the following:
Whether you develop with IntelliJ IDEA, Eclipse or Android Studio, the Backendless library (jar) for Java/Android must be referenced as a dependency. The library includes all the APIs which provide access to the backend functionality. The library is deployed to the centralized Maven repository which makes it trivial to import it to any Backendless-powered app. Below are the instructions for referencing it in Android Studio:
In my previous post I described a feature for conditional pub/sub message delivery using SQL selectors. With that (selector) approach the publisher must attach headers to the message and the subscriber uses an SQL-based condition which references header names and values. In addition to selectors, Backendless supports another type of conditional delivery – subtopics. Consider the following example:
A message with an announcement from Microsoft is published to topic stocks.nasdaq.msft. Another message from IBM is published to stocks.nyse.ibm. Suppose a subscribe wants to receive all messages related to stock announcements. In this case, it subscribes to the stocks.* subtopic. Another subscriber is interested in all Nasdaq announcements. That subscriber subscribers to the stocks.nasdaq.* subtopic. Finally, to receive Microsoft announcements, a subscriber would use the stocks.nasdaq.msft subtopic. As you can see Backendless uses the federated subtopic structure for message filtering/delivery. The sample below shows how to use subtopics in the Backendless messaging API:
Previously I wrote an introduction to Backendless pub/sub messaging which included a sample for broadcasting and receiving messages. Today I am going to show how to use Backendless messaging for conditional message delivery. As you will see in the example, the publisher can attach headers to the published message. The headers is a collection of arbitrary key/value pairs. A subscriber can specify a selector, which is an SQL query defining the condition a message must match in order to be delivered to that subscriber. Each subscriber for the same messaging channel can specify its own selector and Backendless will be handling all of the selectors individually.