Development of mobile applications generally requires two parts: the Backend and the Frontend. Of course, you could limit it only to the client-side, but if there is some data which must be stored on the server, there is no way to get around having a backend. In this series of articles, you will create a native mobile client-server application – a basic ToDo app. Backendless will take care of the backend, it gives you everything you might expecting from the server-side (user management, data persistence and scalability to name a few). And for the client side you will use the Dropsource service. In case if you are not familiar with this service, you can learn more about that from their website, but in short, it is an awesome service which lets you build native mobile apps without any coding. At the end of this series, your will have a native mobile application with the User Registration/Login screen, a screen with a listing of the ToDo items and a screen to create a new ToDo Item. Here’s a brief preview of the app along with real-time changes in the Backendless database:
Make sure you have a Backendless developer account. If you do not have one, you can register at: https://develop.backendless.com
Create a new Backendless Application, I called it DropsourceTODO but you can choose any name you want (there a few limitations in Backendless, but they are very minor).
Register a new account on Dropsource, if you don’t have one. Once you have registered, go to the Dropsource’s Dev Console and create a new project as shown below:
Main App Lifecycle
You might know that in order to perform authenticated requests, you need to pass a special token in the request headers. With Backendless the request header is called user-token. When a user logs in using the login API, the Backendless server returns a user object and also there is the user-token value. This is the value you will use for all subsequent requests to make sure the server handles them in the context of the logged in user.
To begin, create a new
Device Variable for storing the user-token value on the device (follow the red arrows in the screenshot below):
And also let’s save the value in the Keychain storage. To do this, add a new Lifecycle called Application Launched and add the logic for retrieving the value. See how it is done in the screenshots below:
Once it is done, you need to configure conditions for when the value is retrieved. There are two cases, the first one defines what the app should do when the value exists in the Keychain and the second one is when the value does not exist.
In case if
userToken does not exist in the Keychain storage, assign an empty string value to the
userToken Device Variable (repeat the same steps as above for the Keychain Value Not Found and for the value use Static inputs > String without a value:
Now let’s create the first page (screen) and call it the “Lending” page. The page will be the entry point of the application where the app will decide what page based on whether the user is logged in or not (that is if there is an existing userToken value in Device Variables. If the user is not logged in yet, then the app will show the Login Page or otherwise it will be the Todos List Page.
For now you will leave this page, but will come back to it soon.
This is it for Part 1. In the next article, you will build the Login Page, a page for listing the ToDo items and implement basic app routing between the Login and Listing pages.
Happy Codeless Coding!