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.
Earlier this year I wrote about building a sample to demonstrate various APIs of the platform. There is also a post describing the database schema and app’s storyboard. The application is now ready and I will be posting a video tutorial detailing every step of building an app, including the following:
At the end of the tutorial, you will know how to build a data-driven app with Backendless, how to use the User Service APIs (registration, login, email confirmation), with with the relational persistent data, use Backendless console to manage data objects.
Below is an introductory video where you can see the complete app in action.
With Backendless all data accumulated on the server-side belongs to you – the owner of the application. If you ever need to extract all the data from the backend, it could not be easier – Backendless console makes it trivially simple. Data export produces a ZIP file which may contain:
The export process is quite sophisticated, it takes into the considerations any relationships which may exist between the data tables as well as data-to-geo relations. The console provides a way to select the data tables you need to get an export for or with a single click you can select all available data tables. Likewise, you can select either specific geocategories or all of them for export which will include the corresponding geopoints.
The format of the exported data is JSON for application settings and CSV for data records and geopoints. The export functionality is available at Manage > Export in Backendless console. Below is the screenshot of the export user interface:
The Backendless Geservice supports a variety of ways for geopoints. So far we have reviewed how to search for geopoints in a radius or a rectangular area. There is also a partial match geopoint search. In addition to that, Backendless console provides yet another way to search for data – the cross-category search. As the name suggest, this search let’s you run SQL based queries across multiple categories. Enabling that search is very easy:
city in ('AUSTIN', 'DALLAS')
Based on my research of the space we are in Backendless is the only mBaaS platform that lets you use SQL queries when searching for data. The geolocation data managed by Backendless is not an exception. A geopoint may include metadata, which is an arbitrary collection of key/value pairs. Geopoints may be searched for using SQL based queries. A query must be the “where” part of a traditional SQL statement. It can reference the metadata properties as if they are table columns.
The example below uses the sample data which can be installed into any Backendless backend. The data is a collection of geo points representing cities around the world. Each geo point contains metadata with the name of the city. The sample below runs the following SQL query: