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:
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:
Whenever a need arises to quickly create a user for your app, you can always use Backendless console as it makes the process trivially simple. This approach requires no coding at all and the created user can login and start using your application right away.
To create a new user with Backendless Developers’ Console:
There are plenty of use cases when mBaaS-powered applications must use centralized mechanism for incrementing or decrementing a value.There are several approaches for maintaining a counter – some apps use a database, others keep it in the server-side business logic.
Backendless offers a specialized API for working with atomic counters. The API is cross-platform – any number of different clients (including REST) can work with the same counter and update it concurrently. Every counter in Backendless has a name, which is assigned by the client application. The sample below demonstrates the API for incrementing and retrieving the value of a counter.
Backendless provides a very powerful, but easy-to-use API to work with server-side cache. The API is multi-platform, it means clients written in different languages, can exchange data using the centralized server-side cache storage. The caching API can accept any arbitrary object, a primitive value or an array of object/primitive values. Additionally, the caching system can be strongly typed – a client app can specify the type which should be used to deserialize the object.
A user on StackOverflow asked how to load only the data which belongs to the currently logged in user. Although if you read the question it may sound like something else, this is how I understood it. This is indeed an interesting and very common use-case. Backendless (IMHO) handles it beautifully and this feature certainly deserves a place in this feature-a-day series.
What you need to know before we get to the coding sample part is:
Loading data objects which belong to a user does not require any specialized APIs. In fact exactly the same Backendless API you’d use to load objects from the server should be used. The trick is in setting up the security policy to restrict users from accessing data objects and letting Backendless to fall back to what we call the Owner Policy.
A recursive reference is when an object is either directly or indirectly references itself. This design pattern happens rather frequently in applications and quite often distributed systems do not handle it gracefully. Not Backendless – we fully support object recurrence as the same below demonstrates. Consider the following class:
If your native language is not English and you use Backendless to develop applications, more than likely you already know about this feature. When you login to Backendless console, it detects the locale of your computer and switches the user interface to that locale (if it is available). The console has been translated to Japanese, Korean, Chinese, Spanish, Italian, French, Portuguese and Russian. If you add English to that mix, there are nine languages you can experience our product in. I think roughly that would be about 95% of the world population. I think that’s quite awesome!
In my post from yesterday I demonstrated sample code which shows how to search for Backendless geopoints in a radius. While on the same subject I also wanted to review the API for searching for geopoints in a rectangular area. The API is very similar to the one for search in radius, except the app must define the “view port” or the rectangular area on the map where the search must occur. Consider the example below: