In this edition of Backendless Spotlight, we travel to Scandinavia to take a look at an online shopping app from Norwegian footwear company Nordås Sko. Nordås Sko wanted to make it as easy as possible for shoppers seeking professional or work shoes to find what they’re looking for, so they made an app for just that niche. The app is available only in local regions on both the Apple iTunes Store and Google Play Store.
Editor’s Note: If you or someone you know have an app using Backendless for its backend 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.
This week, Backendless Spotlight takes a closer look at Live Love Cite, a mobile app built for the residents of the Cité Internationale Universitaire de Paris. The app acts as a social tool where users can post events, jobs, and items they are looking to sell on the marketplace. Live Love Cite is available on iOS and Android.
Editor’s Note: If you or someone you know have an app using Backendless for its backend 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.
For this series, we are developing an iOS game called “TapMe”. As TapMe is a multiplayer game, it provides registration for the new users and login for the existing ones. In this article, we are going to demonstrate how to handle user registration and login, as well as how to store a player’s information in the database.
The source code for the game is available in the author’s personal Github repo: https://github.com/olgadanylova/TapMe.git
You can read Part 1 of this series here.
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:
We supported Google Sign in for a while, however, the feature was not properly documented. Not anymore )) The documentation has been updated for Android and iOS SDKs. Using the “Login with Google” function, an app can provide a way for the users to login using their Google credentials. Once a user is authenticated, Backendless creates an internal account and starts a logged-in session.
See Backendless documentation for details:
We conducted a webinar titled “Backendless Core Concepts” for ex-Parses last week. A recording of the webinar is now available. The video should be helpful not only if you’re coming from Parse, but for anyone who is starting their journey with Backendless. The webinar reviewed the concepts of Backendless User and Data services. Specifically, we focused on:
- user properties
- setting up user relations
- registering a user
- registering a user with custom properties
- configuring a data model
- code-driven schema creation
- data relations
- a brief overview of Cloud Code
Previously I wrote about the API to send a temporary password to a user (restore password). With the free plan the API sends a password generated by the backend system. However, with a paid plan, the same API works differently. Rather than sending a computer-generated password, user receives in an email a link to a customizable page where they can choose their own password. The webpage which Backendless uses by default is loaded from the file storage allocated to your Backendless backend. You can see it at the
/web/templates/change_password/ directory:
In my previous post I described how to send a temporary password to a user when he cannot login. A password is delivered in an email message. The message can be customized using Backendless console:
- Login to Backendless console, select your app and click the Users icon.
- Click the Email Templates menu.
- Select User requests password recovery from the drop-down menu.
- Modify the email template text using the built-in editor.
- You can preview the email using the Preview button. When you are done save the email template using the Save button.
Previously I wrote about changing user’s password by administrator or via API if user can login. There is also a scenario when a user needs to change password when he cannot login for the reason that the password is forgotten. In this case, Backendless provides a simple API that delivers a temporary password to the user’s email address. The email message can be customized by editing the template for the ‘restore password’ event. This behavior is specific to the apps on the free plan. Applications on the Backendless Plus or above plans provide more flexibility for resetting user’s password.
When a user registers or update his account, application uses the user registration API. It is common for the user interface to enforce the data entry rules and validate the values entered by the user. However, an alternative approach is to perform data validation on the server. Backendless supports user properties validation on creating and updating user objects using regular expressions. Backendless console includes several pre-configured regular expressions for the most common data types, such as email address, URL, social security number and US phone number. Additionally, app developer can specify their own regex. To configure a validator for a user property:
