Message:

Server Code (28 posts)

Images displayed in your app often may be responsible for the bandwidth consumed by the device, which has a direct impact on the performance, battery level and the amount of memory which the app allocates. As a result, optimizing images can often bring noticeable performance improvements for your app: the fewer bytes it needs to download, the smaller impact is on the client’s bandwidth and the faster app will download and render content on the screen.

Let’s imagine you have an app where you store pictures to show them to your app’s users. But what happens if the resolution of these images is high and they are taking a lot of space? Download of these files is time-consuming and, as a result, it slows down your app making the user experience substandard.

A recommended approach is to create image thumbnails with lower resolutions relative to the original one. These thumbnails can be used to preview the image in the application.

The thumbnails can be generated using Backendless API Services (the Business Logic section). If you are not familiar with how to create your own API Service, please check the How to generate a QR code with Backendless API Service post, which describes the process of API service creation in greater detail.

In this article, we will focus on the task of generating thumbnail images with different resolutions.

Continue reading

Suppose your app logs in a user. As a result, the app gets user-token  which uniquely identifies the user’s session with Backendless. If your app uses our SDK for Android, iOS, JS or .NET, the user-token  value is managed directly by our libraries. Specifically, it is added to every API call to maintain the session and tell the server about the user’s identity. There are situations when you need to get the user object when your app has only user-token. This could happen if you used persistent login in the application, which stores user-token on the device. The implementation does not save the user object, however, there is a way to retrieve the user based on the user-token value (assuming the token is still valid). In this article, I will show you how to do this.

The technique for retrieving the user object is creating an API service which accepts a  user-token in the header and retrieves the current user. I will use Codeless to create the API service because it has an intuitive interface and allows you to solve these tasks very quickly, just by building the algorithms instead of writing code:

Continue reading

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.

Backendless Marketplace   Backend as a Service Platform Google Chrome 2018 05 31 21.54.32 1024x568 - How to publish a service to Backendless Marketplace

Continue reading

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:

pasted image 0 4 - How to generate a QR code with Backendless API ServiceYou 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)

Continue reading

This series of tutorials was prepared by:

download - How to create the LinkedIn clone using Backendless

 

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.

https://medium.com/@radiegtya/build-linkedoff-using-react-native-redux-and-backendless-part-1-introduction-9575221f35db

Part 2: RN Setup 

You will do your first steps to get some basic functions for your app.

https://medium.com/@radiegtya/build-linkedoff-using-react-native-redux-and-backendless-part-3-backendless-setup-eb9c8c60197e

Part 3: Backendless Setup

You will get familiar with Backendless and start building the server side logic for your app.

https://medium.com/@radiegtya/build-linkedoff-using-react-native-redux-and-backendless-part-3-backendless-setup-eb9c8c60197e

Part 4: RN+ Backendless; Building The App

You will finalize the visual part of your app and will get a functional Linkedin clone.

https://medium.com/@radiegtya/build-linkedoff-using-react-native-redux-and-backendless-part-4-rn-backendless-c0e5645c89b5

With the introduction of Deployment Models for business logic (Cloud Code), we also added support for “invocation chains”. This is an ability to chain together multiple server-side event handlers registered to process the same event. Previously, you could inject cloud code into the API invocation flow as shown in the image below:

api flow single handler - Cloud Code Event Handler Invocation Chains

For any API call, you could have only one before/after event handler with your own custom business logic. This is changing with deployment models and you can have multiple event handlers chained together:

api flow multiple handlers - Cloud Code Event Handler Invocation Chains

This is a HUGE improvement. It promotes better design for cloud code with a clean division of responsibilities between the event handlers. It is important to note that any data received as arguments for an API call is passed from one event handler to another. If an event handler sitting at the beginning of the chain makes a change to an argument (or the return value), then all other event handlers down the chain will get the modified value.

Setting up chains in console

A question you might be asking is how to configure the order of the event handlers. This is done in the Backendless Console. Consider the following example:

multiple event handlers console - Cloud Code Event Handler Invocation Chains

As you can see there are three "beforeCreate"  event handlers for the "*"  context (which means they apply to every data table). When Backendless detects you have more than one event handler applicable to a particular context, it displays the “handler ordering” icon:

chain ordering icon - Cloud Code Event Handler Invocation Chains

Clicking the icon opens up a popup where you can control the execution order for all applicable event handlers:

We’ll have a video posted to our YouTube channel with a demo of the functionality soon. That’s all for now, guys. Happy coding!

Posted in Server Code

We are preparing one of the final Beta builds for Backendless 4. The build should be released early in the week of June 19th. We plan to release the service out of beta shortly after that. One of the important changes in the upcoming service update will be the introduction of deployment models. When the service is updated with that build, it will be necessary to redeploy your business logic (API Services, Event Handlers, and Timers) using the latest release of CodeRunner. If you do not do that, any existing business logic in the Backendless 4 apps will stop working.

We realize it is going to cause an inconvenience – we really wanted to avoid it. However, the service is in beta and we thought you’d cut us some slack.

If you have any questions about this, please ask either on the support forum or our slack channel.

One of the new features we will be releasing in the final update of Backendless 4 beta is support for “business logic deployment models”. This is a new concept introduced in Backendless 4. A “deployment model” combines individual API event handlers, timers and API services into a single group. The purpose of that grouping will become more apparent once we start opening up Backendless Marketplace for submissions, however, the introduction of this feature already opens some very cool features.

This change will be available in the Backendless 4 applications the week of June 19th.

Some important things to keep in mind when working with deployment models:

  • Models are associated with languages. It means a model with the same name may exist with Java business logic and JS business logic, but it is not the same model – they will contain different business logic.
  • A model cannot contain more than one API event handler attached to the same “asset”, which is a table/file/messaging channel. This means, for instance, if you have a JavaScript “afterUpdate” event handler processing events for the “Person” table and the event handler is in model “X”, the same model “X” cannot have another “afterUpdate” handler for the table “Person”.
  • Contrary to what’s stated above, you can have the same kind of an API event handler in different models.
  • When downloading code from the Backendless Console, you must identify the language and then the model for which to download the code.
  • When deploying code using CodeRunner (JS or Java), the deployment model name for the code must be specified either in the CodeRunner’s configuration file or from the command line.
  • Deploying code into a model deletes all previously deployed code in the same model.
  • When the code is debugged locally (while being plugged into the Cloud servers), it takes precedence over the same code which may have been previously deployed. In other words, the Debug mode has higher precedence than the Production mode.

Let’s take a look at how to work with the deployment models:

Creating new event handlers and timers

When creating an event handler or timer in the Backendless Console you will see a new drop-down list where you can select an existing model. To create a new one, simply type in the desired model and click the menu option to create it. The screenshot below is for creating a new event handler. You will see an identical change in the “New Timer” popup:

event handler model - Deployment Models for Business Logic

The Event Handlers screen in console displays the model name for every handler (see the MODEL column):

multiple event handlers - Deployment Models for Business Logic

When you download the generated code for event handlers and timers, you need to choose the model for which to download the code. The downloaded code contains only the event handlers and the timers for the selected model:

downloading model - Deployment Models for Business Logic

Similarly, if you were to edit the code directly in the Backendless Console on the CODING screen, you need to choose the language and the model. The displayed tree of directories and files will contain only the code for the selected model:

models in coding - Deployment Models for Business Logic

For most use-cases, you will find it sufficient to work with the same model. We considered how developers use business logic now and tried to make the developer experience mostly unchanged.

Posted in Server Code

For anyone developing business logic in JS, we have put together some suggestions for troubleshooting your deployment. The page is added to the product documentation. One of the new features described in the doc is the ability to redirect console.log  messages to Backendless logging. Once your JS code is deployed to production, messages from the console.log  calls will be routed to the log file wit the SERVER_CODE  logging category.

timerlog - Troubleshooting JS business logic

Backendless API Engine is a service container enabling Backendless developers develop and run arbitrary Java, PHP and very soon JavaScript/Node.JS code as API services. With the service and CodeRunner update we deployed earlier this week, there is a awesome new feature which allows you to debug your services locally before publishing them into the cloud. The video below is an overview of the debugging process, it also briefly reviews the workflow for creating a new service. Enjoy!

Find us in facebook