Sometimes (or in some cases, every time) when you invoke a custom API Service, you may need additional information about the context from which the HTTP request was sent/received, such as user or device information. To collect that information, we provide a class called InvocationContext .

In a previous article (Developing a Custom Skill for an Alexa Game), we showed you how to build a custom Alexa skill using Backendless and our Amazon Alexa Skill SDK. We made a game called Guess My Number that was played using Alexa. Now, we are going to show how to make the same game using our Codeless feature – in other words – without any coding!

You can read more about what Codeless is and how it works here.

When building a mobile application, as a rule you will need to implement two parts: a backend and a frontend. Of course, we can confine ourselves to only the client-side (frontend), but when we have some data that should be stored on the server, we need to have the capability to capture it.

Today, we will create a simple native mobile application with both parts, and we will be doing so with no coding whatsoever. Backendless will handle our backend; it gives us everything that we need from the server-side. For development of the client side, we will use a service called Dropsource. In case if you aren’t familiar with this service, you can read more about it on their official site. In the end, we will have a simple native mobile application with a Sign Up/Sign In screen, ToDo List screen, and Add New ToDo Item screen. The app we will be building today will be native for iOS.

Let’s do it.

In this article, we will show you how to write a service that will backup your application data with a time interval you specify. To do this, we will be using custom business logic, a timer, and the console SDK.

The result of this operation will be an archive with the data of all your tables (or, if you wish, you can modify the service for backing up specific individual tables, geo-points, application settings, etc.).

Today we are going to demonstrate how to create and save new data objects using the very convenient REST Console in Backendless. We will start by opening our Backendless application and navigating to the REST Console. To do this, go to the Backendless Console and select the Data tab.

In this edition of Backendless Spotlight, we visit the Pacific Northwest where a group of local leaders have created an app to guide tourists through an historically significant part of Tacoma, Washington, known as Japantown. The app provides a map with important landmarks and places of interest, historic and modern photos of each location, and links to essays and notes compiled by historian Michael Sullivan and writer Tamiko Nimura. You can download the app on the Apple App Store and Google Play Store.

Editor’s Note: If you or someone you know have an app using Backendless and would like to be considered for a future Backendless Spotlight, we want to hear from you! Send us an email with a link to the app or website and a description of how Backendless has helped them be successful.

Today we’re going to take another look at security configurations in Backendless. In this article, we will talk about how to restrict direct access to your data via API and only expose your custom API endpoints. This does not mean you should use some other set of “admin” APIs for data management. Instead, it is accomplished by setting up proper security settings.

Backendless provides ways to set up really granular permissions for your resources, including even row-level security in your data tables. But for this task, we’re only going to need system roles and global permissions. Thus, it won’t require you to do a lot of configurations or create additional assets, such as custom roles.

Today we are going to walk you through the process of allowing users to register and log into your app using their Google account. The best way to showcase this is to walk though the Registration and Login example app available in the Code Generation section of your Backendless Console.

Have you ever wondered why is it often so tedious so make your simple Java app a web server, with the methods becoming the endpoints? You need to add libraries, write additional “web” wrappers, set up a server and a hosting, configure load balancing and much, much more. Do you really have to go through all these things when you just want this piece of code be available via the Web so that others can invoke it and get some fancy results?

The good news is that nowadays this is much less of a problem: with services like Backendless, it is easy to transform your custom code into a real REST service available via both REST and JS/iOS/Android/Java APIs. If needed, authentication also comes available out-of-the-box. It is worth noting that this is all for no charge except for the number of API services you may have and the number of API calls you’ll make to the service in a month.

In this article, we’ll show you how to make your HelloWorld app really say Hello to the whole World.

As you may have noticed in our release history, the EXTENDED STRING data type was removed almost a year ago. To be precise, it was more a merge of the STRING and EXTENDED STRING data than the removal of the latter. This means now you can safely use STRING data type for any kind of characters (including emoji! ????) without worrying if the column would support it. In addition, the sorting order for multiple non-Latin languages has been fixed automatically.

Relieving developers from the hassle of two string types has always been one of our main goals, and this is another small step in that direction.

In this post, I’ll explain our reasoning for introducing the somewhat confusing EXTENDED STRING data type earlier and how we managed to finally solve the initial problem with no additional complication for the developers using our platform.