Messaging (6 posts)

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 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:

Continue reading

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.

Continue reading

In my previous post I introduced the publish/subscribe messaging API. The API can be used to broadcast messages which can be received by multiple client apps.

Note: it is important to distinguish the pub/sub messages from the Push Notification ones. There is a number of technical differences and the purposes where an app should use one mechanism or the other.

When developing and debugging applications which use the Backendless pub/sub API, it may be very handy to publish messages without writing additional code. For this purpose, Backendless console supports the message publishing function. To see it in action, run the subscriber code from the previous post and then:

  1. Login to Backendless console, select your app (must be the same app which the subscriber app uses) and then click the Messaging icon.
  2. Make sure the default messaging channel is selected. Enter the text of the message into the Message text area and click the Publish button.
  3. The message will be displayed in the table of messages in the Messaging screen as shown in the image below. Additionally all the subscriber apps receive the message.


Publish/subscribe messaging has been around for a long time. The concept is rather simple – a program can publish a message to a queue or a topic, while another program subscribes to the queue or the topic to receive published messages. There are a lot caveats in the model with conditional delivery, message filtering, message transformations, etc. In this post I will demonstrate the most basic form of publish/subscribe messaging. One client will be publishing basic string messages, while any number of other client apps can subscribe to receive published messages. Consider the following example:

Continue reading

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:

Continue reading