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.
Make sure you have a Backendless developer account. If you don’t have one yet, you can register for free at develop.backendless.com.
Create a new Backendless Application. I called it “DropsourceTODO”, but you can choose any name what you want.
Register a new account on Dropsource if you don’t have one yet. Go to their Dev Console and create a new project, as on the images below.
Click the “Open Editor” button to start creating our app.
Main App Lifecycle
As you know, to perform authenticated requests you need to pass some token in the request headers. In the case of Backendless, the header is called ‘user-token’. So on the user login request, the server returns a user object as well as a “user-token” value. We will use that value for all the requests.
First, let’s create a new Device Variable for storing the user-token value locally. The data type should be a Swift string.
Let’s also save the value in Keychain storage. Add a new Lifecycle in “Application Launched” and add some logic for retrieving the value. You can see how it’s done on the following screenshots:
Once that’s done, we need to configure the conditions when the value is retrieved. There are two cases: the first is what we should do when the value is existed in Keychain, and the second is if it isn’t.
So, if the user-token exists in Keychain storage, assign it to the userToken Device Variable.
In the event that the
userToken does not exist in Keychain storage, just assign an empty string value to the userToken Device Variable.
Now let’s create the first page of the app and call it “Landing”. The page will be an entry point to our application where we will choose what page we need to show according to the existing userToken value in Device Variables. If the user is not logged in yet, show the Login Page. Otherwise, we will show the ToDo List Page.
Let’s create the page and modify some styles (if you want) as described on the following screenshots.
Ok, now we’re going to leave the page, but we will come back soon.
Next let’s create a simple page for user SignUp/SignIn and style the page as you wish.
Add some actions for hiding the keyboard when an input is returned. Add the action for both inputs.
We’ll leave the page without any logic for now. We will come back to the page once we’ve created other pages.
Create a simple page for displaying our feature ToDo items. On the page we also need a Navigation Bar. To create one, just select the checkbox when you create a new page.
Now that we have these two screens, we can implement a simple routing for switching between the Login Page and the List Page according to the existing userToken in our Device Variables.
Go to the Landing page and open the events section.
Ok, now add logic for showing the Login Page when the condition is TRUE, and showing the List Page when it’s FALSE.
Ok, let’s check if we are on the right track and we’ve done everything right. Let’s run our app and see how it looks. To do so, click the TEST button on the top of the browser window. Wait a little then run the application in the Web Simulator.
As a result, you will get a simple app. If have the same result as me, keep going. In the event that you are not able to run the application, please go back to the previous steps and check to see if you missed something.
Backendless API Docs
Now we can integrate Backendless API. Before we do that, we have to create a new table in the Backendless Dev Console. I called the table “TodoItems” and also specified two columns for the table, “title:STRING” and “completed:BOOLEAN”.
Let’s generate API Docs for that table. Go to the REST Console section and click the “Generate API Docs” button.
Once the popup opens, click the “Generate” button. It will generate API Docs for the table in Swagger 2.0 format and save it in our Backendless App.
Now copy the public URL of the generated file and go to our Dropsource App.
The generated API Docs include all the API for the table “TodoItems” and the User API as well, so we don’t need any additional API docs from Backendless.
Looks like we’ve done everything what we need for our API requests to go to the server, so let’s set those up.
The first thing we should do is link our “userToken” Device Variable with the API that we added in the previous step.
Now add an API request to the Login page.
Then link our Email/Password inputs to the request. To do so, just drag and drop the request body params into the inputs.
Ok, now add an event to the SIGN UP button. When tapped, we need to run an API request to register a new user.
You may ask “what if there’s an error? How do we handle a response error?” Alright, let’s cover that now.
First, we need to add a Label Component for displaying the error and some dummy error text for testing. Once you place the component, remove your dummy error text. Next add a reference between the component and the API Request.
Ok, let’s check this out. We will try to register a new user with an invalid email address.
Right after user registration, we will do another request for user login. For that, add API to the user login and link inputs with the request parameters.
Once that’s done, let’s add the Login API Request right after the Registration Request only if the register request returns an HTTP Status Code 200. That way, when a user registers, they will also automatically login to the app.
Also add error handlers for the Login API Request just as we did for the Register API Request.
Now let’s add an action when tapping on the SIGN IN button. When it’s tapped, we should run the Login API Request.
Now there’s only one thing remaining with this screen. When the Login API Request return status code 200, we need to store the ‘user-token’ into the Device Variable, keep the value in Keychain, and show the List page.
First, let’s set user-token from response into Device Variable.
Next, set the user-token into Keychain storage.
Then, show the List page.
Let’s run the app again to see if everything is working.
If we have a user login, we need to have a user logout as well, so let’s add that.
First, we need to reset the userToken Device Variable.
Next, delete the userToken value from the Keychain.
Third, we need to show the Login Page.
Finally, run a Logout API Request and move up the action to the top.
The main goal of our app is having a ToDo list with the ability to create new items and toggle their completed state. So go to the List Page and add a Dynamic Table Component and switch the Table View to “Dynamic”.
Then add a Table Cell View, Label, and Switch Components into the Table View.
Alright, let’s add the API Request for retrieving TodoItems objects.
Now we assign the response to our Table View.
Time to decorate our Table Item View. Let’s add a Label Component and Toggler for switching completed state, and assign the title and completed properties from the response body.
Add an API Request for loading the TODO items when the List Page is loaded.
Now add an API Request for updating a TODO item.
Link the objectId into the request path parameters.
Now add an action when we toggle the TODO item toggler.
The add the new “completed” value into request.
Ok, let’s take a look what we have now. Click the TEST button at the top and while the app is building, go to Backendless Console -> Data Browser and create a few records.
Once the app build is done, run the Web Simulator and check it out.
Add New Item Page
Now let’s create a new page for adding a new TODO item.
Make sure that you have both the “editable” and “selectable” checkboxes checked for the Component.
Add an action for switching to the page.
Also, set up a “Back” button in Add Item Page.
Next, add the API for creating a new TODO item.
The link the request parameters.
Add the API Request action to the SAVE button.
Now add an action to go back to the previous List Page when the API Request for creation of a new item is complete.
Delete TODO Item
Let’s add an ability to delete TODO items with the swipe effect. First, we need to add an API Request for deleting the TodoItems object.
Also, link the objectId to path params.
Once you’ve completed those steps, select the Table Cell Component and add an “on swipe” action.
Now we need to add three actions. First, run the API Request for deleting TODO items.
Second, getting current Table Cell index.
Third, remove the Table Cell from the table.
That’s all! If you’ve hung in there this long, you can now build your app and try to add/remove TODO items.
As you can see, we created a real native mobile application with User Auth and Data Service without any coding. These two services (Backendless and Dropsource) can help you do far more than we did today; this was just a little part of their possibilities. This was just a simple application to show you how to use them together.
Thanks for reading the article and I look forward to seeing what you are able to build with Backendless and Dropsource!