As an mBaaS platform we frequently say “no server-side coding is required”. This is true for a lot of apps, however, at times it is necessary to shift some application logic to the server-side. The logic may need to alter or extend the default implementation of the core services. Adding custom business logic is not only easy with Backendless, but the process is really cool and exciting. The combination of a code generator with the local debugging option makes it a killer feature. The video below will walk you through the process of adding custom business logic to Backendless. Enjoy!
Geolocation is one of the core services of Backendless.
Using the Geolocation API you can easily add a sense of location to your application. Backendless provides a powerful mechanism for metadata-based searches in a geographic area (rectangle or radius). The latest release of Backendless includes an entirely rewritten Geolocation management interface in the Backendless Console.
This video provides an overview of the capabilities we added to the product:
We just pushed a new release to our production servers. The release includes multiple new features and a ton of improvements. Below is a summary of what went into the release. There will be a blog post with a video providing an in-depth review of each new feature:
CocoaPods manages library dependencies for your Xcode projects.
The dependencies for your projects are specified in a single text file called “Podfile”. CocoaPods resolves dependencies between libraries, fetches necessary code and links it together in an Xcode workspace to build your project.
This article reviews the APIs for working with relational persistent data in Backendless. By the end of the article, you will have a working application which demonstrates various mechanisms for loading related data objects from the backend-as-a-service data store. To avoid any terminology confusion or overlap, let’s define related data as multiple objects referencing one another in the object-oriented data model. For example, suppose there is a class called Order. The class aggregates (references) a collection of OrderItem’s. This is a one-to-many relation. The OrderItem class has a one-to-one relation with a class called Manufacturer. Consider the following diagram:
The goal of this post is to let you quickly become familiar with Backendless custom business logic feature. At the end of the instructions provided below you will have a Backendless application with a custom API event handler published into production – that is running on our servers.
It feels amazing to begin writing this post. I have been waiting for a long time to say it and I finally can – Backendless goes out of Beta! And boy, aren’t we doing it with quite a bang. Over the weekend we pushed a new release with a ton of fixes and some amazing functionality. It took us quite a while to get to this point, but I am quite sure the wait was worth it. The new release includes support for custom business logic, code generation, data validators, multi-environment (dev, test, stage, prod) support and many more. Please see below for details:
Establishing relations between user objects and other entities in an application is a very common use case. This post describes various scenarios and shows sample code using Backendless SDK for Java/Android and Backendless SDK for iOS. Make sure the version of the client libraries are at least 1.5 for Backendless Java/Android and 1.11 for iOS.
Tizen is an open source platform residing within the Linux Foundation. It includes an operating system which can run smartphones, tablets, netbooks, onboard devices in smart cars as well as smart TVs. We wanted to see what it would take to integrate a Tizen app with Backendless because the benefits of such integration would be huge. For instance, data can be easily shared between different implementations of an app: a Tizen version of the app can easily communicate with the one running on Android or iOS by the means of Backendless service APIs.
Our Data Service supports a very flexible security mechanism for restricting access to objects stored in Backendless. Security permissions apply to users and roles. A permission can either grant or reject an operation for a particular asset. In the context of Data Service, the asset is an object which your app can retrieve, update or delete. Permissions can be granted or rejected globally, where they apply to all tables and all objects in the data store. Additionally, every table may have its own permission matrix and owner policy – a special instruction whether object owners can or cannot retrieve/update/delete the objects they ‘own’. Finally, every object has its own Access Control List (ACL) which is a matrix of permissions for the operations applicable specifically to the object: