Backendless Marketplace is a specialized store for backend functionality. Our vision for the marketplace is to make it a community driven store for algorithms and API services. We also use the Marketplace for various Backendless”extenders” to help developers to increase the limits of the Backendless Cloud pricing plans. However, most importantly, the Marketplace can be used for sharing your API services with other developers.
By publishing your Cloud Code to the Marketplace, you can share your business logic components (e.g.: API services, event handlers and/or timers) with other Backendless developers. Once your Cloud Code is published, it becomes a Marketplace product and will be visible to all Backendless users (developers). In the upcoming releases, we’ll add a possibility to set a price for your products allowing you to charge a fee for every successful installation.
Today we will talk about the integration of Backendless into your AngularJS/TypeScript app. You will create a simple Address Book application where all the application data will be stored in the Backendless mobile backend. The main goal of this article is to provide step-by-step instructions and to show how to create an Angular application with Backendless mBaaS.
In this article, we will learn how to create QR codes with a custom Backendless API Service. For the sample code reviewed later in the article we will use Java and the ZXing library (https://github.com/zxing).
What is a QR code?
A QR code is a computer generated image with some information encoded in a graphical way. The information may include text, numbers, a URL – pretty much anything your app may need to represent in an encoded manner. What makes QR codes very useful is the encoded information can be then decoded by any device with a camera.
Below is an example of a QR code with the encoded link to Backendless Console: https://develop.backendless.com:
You can ‘read’ it with an iPhone (just use the standard camera app) or with an Android device if you install a QR Code reader app (check out Google Play, there is a ton of QR reading apps). Once the code is scanned, the encoded URL will be opened automatically in your web browser.
(For more details, click here: https://en.wikipedia.org/wiki/QR_code)
This series of tutorials was prepared by:
Ega Wachid Radiegtya
An Entrepreneur & App Developer
You will learn how to make your own LinkedIn clone on Android, using React Native, React Navigation, Redux and Backendless.
The following tutorial series is exactly what you’re looking for if:
- You have a basic knowledge of React/Redux
- You’re looking to learn how to make apps in the most simple way
- You want to try using mobile backend for your apps
Technology stack:
- React
- Redux
- Backendless
What you will learn:
By following the instructions in these articles, you’ll get the knowledge and skills required to build simple Android apps using Backendless mBaaS for your business logic.
Summary:
Part 1: Introduction
You will learn about the tools required for the task and how to set up the development environment to proceed.
Part 2: RN Setup
You will do your first steps to get some basic functions for your app.
Part 3: Backendless Setup
You will get familiar with Backendless and start building the server side logic for your app.
Part 4: RN+ Backendless; Building The App
You will finalize the visual part of your app and will get a functional Linkedin clone.
Backendless and Firebase, both being mobile BaaS platforms, are presenting different capabilities for mobile apps creation.
Here is a list of the Backendless features which either are not supported by Firebase or just exceed it in usability.
- Backendless Pro (the standalone, self-hosted version of the product) can be installed on the developer’s computer, a private data center or a public cloud. No matter where it’s installed, the product has no functional limitations whatsoever
- With Backendless you can fully customize permissions for users, and also configure permissions for custom user roles, which is not supported by Firebase
- Backendless allows you to develop the server-side algorithms and business logic without actually writing any code using Codeless Programming
- Firebase does not support native aggregate functions in database queries. With Backendless, you can calculate average, sum, min and max values for a collection of objects without retrieving objects from the server. It is also possible to find the object count for all the records in the database or a subset of records
For example, the aggregate function sum allows you to calculate the mathematical sum for a set of objects. For instance, you can take the Movie table from the presented database.
Just run the following query to get the amount of topBoxOffice of all movies:1GET https://api.backendless.com/<appid>/<REST API key>/data/Movie?props=Sum(totalBoxOffice)
The output is an object with the sum property:123456[{"sum": 14507795640,"___class": "Movie"}]
Backendless also supports results grouping for a column. This column can either be found in the original or linked table. For example, the following query will display the sum of all the orders grouped by a country:1GET https://api.backendless.com/<app id>/<REST API key>/data/Orders?props=Sum(orderAmount)&groupBy=relatedCountry.countryName
The output for this request is a collection of objects, any of which contains the total amount of orders for a particular country:1234567891011121314151617[{"sum": 1324231,"countryName": "Italy","___class": "Orders"},{"sum": 5675675,"countryName": "France","___class": "Orders"},{"sum": 2342234,"countryName": "Ireland","___class": "Orders"}]
You can also add a filter to the grouped objects using the having condition. The following query will return only groups of countries with the total amount of orders > 10000 . The output for this request is a collection of objects, any of which contains the total amount of orders for a particular country:1GET https://api.backendless.com/<app id>/<REST API key>/data/Orders?props=Sum(orderAmount)&groupBy=relatedCountry.countryName&having=Sum(orderAmount)>10000 - Since Firebase uses JSON document as a database, it becomes extremely difficult (or in many cases impossible) to create relations between objects. Backendless makes it convenient to manage the relations (create, modify, delete) both via Console and with the API. In Firebase, you need to duplicate the data for each element, which causes synchronization problems for the identical objects that have one-to-many relations.
It is worthwhile to point out the following:
- Backendless allows you to import data from Parse. Importing data from external databases will become available soon as well
- Firebase, unlike Backendless, does not allow you to make complex queries on the server, only basic filtering is supported. For more details see: backendless.com/docs/rest/doc.html#data_search_with_subquery
- The Backendless Console is way more convenient and has more functions, compared to the one in Firebase
- Backendless support is beyond comparison. Here’s what real users have to say
- Backendless version 5 launch happens soon! New features are described here
In this article, we’ll talk about Backendless publish-subscribe messaging. One of the frequent questions we receive is: ‘How to get messages long after they are published.’ The default mechanism in Backendless keeps messages in the published channel for a short period of time only (around a minute). This becomes a problem if subscriber needs to have access to the messages after that time period has passed. This article describes an approach for storing published messages in Backendless database in order to keep published messages accessible even when they are no longer present in a messaging channel.
Publish-subscribe is a Backendless messaging pattern. The main idea here is to exchange data between a publisher* and subscriber** within a messaging channel***.
* publisher – a program using the Publishing API to send messages to a channel.
** subscriber – a program using the Subscription API to receive messages from a channel.
*** channel – a logical intermediary “transporting” the messages.
In order to keep messages accessible for an infinite period of time – you can save messages into the Backendless database right after they were published. To accomplish this, we’ll need to combine Data service API and the afterPublish event handler which can be added to the Business Logic tab of your Backendless application.
Once it’s added, just download the afterPublish handler code from ‘Download’ menu (you can select JavaScript or Java). Then open the generated project in any IDE and add the code to store published messages in a Backendless data table.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
@Asset( "chatRoom" ) public class DefaultChannelEventHandler extends com.backendless.servercode.extension.MessagingExtender { @Override public void afterPublish( RunnerContext context, Object message, PublishOptions publishOptions, DeliveryOptions deliveryOptions, ExecutionResult<MessageStatus> result ) throws Exception { String publisher = publishOptions.getPublisherId(); String messageData = message.toString(); HashMap savedMessage = new HashMap(); savedMessage.put("publisher", publisher); savedMessage.put("messageData", messageData); Backendless.Data.of("ChatHistory").save(savedMessage); } } |
Alternatively, the
afterPublish event handler can be added and deployed to cloud without any coding at all using Codeless business logic. Here are the steps of how it can be done:
1. Add new Codeless event handler 
2. When the handler is saved, Codeless designer will be opened. Add the following blocks to your Codeless logic. When done – click the ‘DEPLOY MODEL’ button.
Voila!
To avoid nulls, every message should be published with a not null value for publisherId :
|
1 2 3 4 5 6 7 |
public void publishMessage() { PublishOptions publishOptions = new PublishOptions(); publishOptions.setPublisherId("Jack"); String message = "Hello, this is my first message!"; Backendless.Messaging.publish("chatRoom", message, publishOptions); } |
For this scenario we’ll need to create a data table (Data > APP TABLES in your Backendless application) called ‘ChatHistory’ and define the following schema in it:
- Column publisher of type String
- Column messageData of type String
Once code for the handler is added, deploy the handler code to cloud using the following command in your IDE terminal:
./bin/Deploy.sh
Since the handler is deployed, every new message published to
chatRoom channel will be stored in a dedicated data table and will be accessible at any required moment by calling an API to retrieve data from a table:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public void retrieveMessageHistory() { DataQueryBuilder dataQuery = DataQueryBuilder.create(); dataQuery.setOffset(0); dataQuery.setPageSize(100); dataQuery.setSortBy("created"); Backendless.Data.of("ChatHistory").find(dataQuery, new AsyncCallback<List<Map>>() { @Override public void handleResponse(List<Map> response) { for (Map message:response) System.out.println("Publisher: " + message.get("publisher") + "\n" + "Message data: " + message.get("messageData") + "\n" + "Posted at " + message.get("created")+ "\n\n"); } @Override public void handleFault(BackendlessFault fault) { System.out.println("Error retrieving message History: " + fault.getMessage()); } }); } |
You will receive the following output:
|
1 2 3 4 5 6 7 8 9 10 11 |
Publisher: Jack Message data: Hello, this is my first message! Posted at Mon May 21 19:53:13 EEST 2018 Publisher: Jack Message data: And this is the second one Posted at Mon May 21 19:53:40 EEST 2018 Publisher: Mike Message data: Hi, Jack! Posted at Mon May 21 19:54:13 EEST 2018 |
It has not been a year since we released version 4 into GA (it went live on July 3rd, 2017). There were 48 “point” releases between then and now, but we also have been hard at work on the next major version of Backendless – version 5. The new release will be backward compatible – when the release goes live, your applications will continue to work as before. If you decide to upgrade the client-side libraries, you will get access to all the functionality in the new version. What does the roadmap for version 5 look like? See answer below:
- Real-time Database – your app can subscribe to receive real-time updates when new objects are created in the database, or existing objects are updated or deleted.
- Real-time Publish/Subscribe messaging – we changed the subscription model so the published messages are pushed to the client applications instead of the current “pull” model.
- Real-time logging console – See and inspect your app’s log messages in Backendless console in real-time.
- Remote Shared Objects (RSO) – This is a jewel of real-time messaging. Unless you had experience with RSOs in the Flash/Flex world, it will be a new concept for you. Wait for the release and be prepared to be amazed.
- Redesigned Push Notifications Support – we have completely rebuilt support for push notifications. Virtually every push notification feature available in the latest Android and iOS versions will be supported in Backendless 5.
- Mobile Landing Pages – We added a simple CMS (content management system) so you can create a landing page for your mobile app and host it in Backendless.
- Zapier Integration – Connect your Backendless backend with 1000+ external services and APIs available in Zapier. Virtually every single API in Backendless would be available as a trigger or an action in Zapier.
- Phone-based Authentication – We added 2FA and the users of your apps will be able to login without any stored passwords.
- Integration with External databases – This is a feature available only in Backendless Pro. It will let you connect your Backendless app with an external database (Oracle, MySQL, SQLServer, PostreSQL)
- Docker-based architecture for Backendless Pro – Backendless Pro is changing to be based on Docker. This will allow for better management, scalability and software updates.
The real-time functionality is what slated for the 5.0 release. Other listed features will become available with the subsequent minor version releases.
We are very excited about Backendless 5 and I am sure you will love it too!
The release of Backendless 4.5.0 introduces support for file search in Backendless console. We already had search API in our SDKs (Android, iOS, JS, REST) and based on the feedback from the customers added search support in console. Here’s what you can do now in console:
Basic search
Type in a partial or full name of the file. Backendless displays a list of search results with the corresponding path. Clicking the file name in the “Name” column opens the file in a new browser tab. If the search result is a directory, clicking it will open the search result screen for that directory. There is also the “Search in subdirectories” checkbox, the meaning of which is quite self-explanatory:
Search with a glob pattern
The search query can use the glob syntax to express patterns for file and directory names:
Search in Create a File Relation
Your database schema may include columns with the FILE REFERENCE type. Here’s an example of such data table column:
When you establish a relation with a specific file, you work with the popup shown below. As you can see, it now has an ability to perform file search:
Enjoy!
All available APIs for creating, updating and deleting objects in the Backendless database operate on single objects. It means when you need to store multiple objects in the database, each object requires a separate API call. This increases the number of API calls your app makes. While it is great for us (hey, our billing is based on the API calls), it is not that great for your app as it results in longer processing times and substandard user experience. Starting today, with the release of Backendless version 4.5.0 we’re introducing the new APIs which will allow you to create, update or delete multiple objects with a single API call.
Bulk Create
Saving multiple new objects in the database is now as simple as passing an array of objects to the server. The server responds with a collection of objectId values (which, for example, can be used in the createRelation API). The bulk create API is supported in all SDKs as well as the REST interface.
Bulk Update
To update objects in the database, the API accepts a condition (where clause) which identifies a group of objects. In addition to the condition, the client must also provide an object containing the changes which should be applies to the selected objects.
Bulk Delete
Similar to “Bulk Update”, this API receives a condition which identifies a group of objects to be deleted.
All of the APIs can be extended using custom business logic’s before/after events.
You can find the documentation for these APIs in the developer guides:
- Android:
bulk create, bulk update, bulk delete - iOS:
bulk create, bulk update, bulk delete - JS:
bulk create, bulk update, bulk delete - REST:
bulk create, bulk update, bulk delete
If you have any smart IoT devices in your home or office and tried controlling them with Alexa, you might wonder how it actually works. In this guide you will learn about building a custom Alexa skill which will let you control a wi-fi enabled light bulb with Alexa. You will be able to turn the light on/off and change the light colors. You can see a demo of the completed project as well as an overview of its components in the video below:
The solution consists of the following components:
- Amazon Alexa-enabled device (Amazon Echo)
- A custom Alexa skill, which is an API service running in Backendless
- Backendless SDK for Alexa, which provides functionality greatly reducing the amount of work you need to do when working with Alexa requests.
- An API service which contains the logic of controlling the light bulb
- A wi-fi enabled light bulb, for this we used a LIFX bulb.
