Dariusz Orasiński – firstname.lastname@example.org
Jebisan Nadarajah – email@example.com
This blog is documenting the work which has been done as a part of the iOS elective course held for final year students of the University of Southern Denmark Master Degree in Software Engineering. This blog is about documenting the whole process behind developing an iOS application written in Swift programming language and developed using Xcode IDE environment.
The product itself is an iOS application that helps people to share their wishes amongst their friends and family members. The group believes that this is a solution for the overall problem, where people receiving gifts which they don’t desire.
The group defined its objectives as follows:
- Develop an iOS application in Xcode IDE environment
- Use MVC pattern as an overall structure
- Make use of minimum two build-in sensors available on an Apple Smartphone device
- Make use of elements such as Multiple Views, Table View, View elements and more
- Create an application with light and user friendly design
The overall aim and goal is to create an application that uses mentioned objectives.
Methods and materials
In the initial phase of this project, the Brainstorming were performed in order to gather the ideas for an iOS application. This was done by using Freemind software tool, where the ideas for the project were written and visualized in form of bubbles with text. Afterwards the ideas were ranked in order to define the best one.
Once the initial idea were defined, the simple prototypes were developed as a part of the conceptual design phase. For the purpose of creating a simple prototype, MarvelApp were used. Marvelapp is free web application where low- and high-fidelity prototypes can be developed and presented to the users.
Use case diagram
The purpose of Use case diagram is to represent user’s interaction with an system or software mobile application, and for this purpose it was used during this project. The use case diagram were created in draw.io which is a free modelling software provided by Google.
All functional and nonfunctional requirements were gathered from use case diagram, developed in a previous stage of the project. This requirements were ranked by using MoSCoW method, in order to understand and prioritize the requirements that were most important for this project, and those which could be implemented as extra features.
For the software architecture design purpose, a MVC diagram was created to provide an overview of following objects within the iOS mobile application developed in this project:
- Model – representing data layer for the application.
- View – representing view layer where users typically interacts with the application.
- Controller – representing controller layer, where the logic that controls model layers with view is performed.
The result of the MVC architecture is presented in Result section.
In order to implement the application based on the requirements from previous section, the design choices were defined followed by development environment choices.
Development environment of this project consisted of following elements such as: Xcode IDE, Swift language and GIT virtual version control.
The Xcode IDE is an developer tool for macOS which allows to create software or mobile applications for iPhone, iPad or Apple watch and Apple TV. The Xcode supports many programming languages, however for this project it was decided to develop application in Swift. Swift is programming language developed by Apple and suited for their operating systems such as iOS, iPadOS or macOS.
GIT distributed version control is a free system to controlling changes in source code during an development process. It was used during development process of the application and allowed both members of this project group to work independently and or on different features at the same time, without causing any delays in the project development process.
iOS mobile application
Based on the initial idea as well as development choices, it was obviously to developing an mobile application for an iPhone smartphone.
Following frameworks and libraries were chosen for developing of the application.
- Facebook SDK framework – this was used for the login feature
- Core location and MapKit libraries – this was used in several view controllers within application
- UIKit – this was used in several view controllers within application
Database and Server
The database and server is a important part of this application. It was decided to use Google Firebase for server and realtime database.
The group came out with two different propositions for the overall design of the application. The first design can be seen on Figure 1. In this prototype, the main focus was to define the overall style and look of the application:
Figure 1 – First possible design.
In the second prototype which can be seen on Figure 2, the main focus was to define the overall functionality with less focus of the overall style and look of the application. This prototype also represents the add Wish function which was missing in the previous prototype:
Figure 2. Second possible design
Both prototypes were presented to the group of people with positive feedback. Afterwards, the group decided to combine these two prototypes. The iWish application inherited overall look from the first prototype. The add Wish function and the TableView element were highly inspired by the second prototype. The merge of the two prototypes resulted in this final prototype:
The group decided to create Use Case diagrams, to have an idea about the basic app functionality. The Use Case diagram below, represents the overall functionality of the app from the viewpoint of the user.
The figure below represents the initial object diagram for overall MVC structure for iWish application. As it can be seen below, the initial object diagram consisted of five views and controllers followed by a single model that represented wish object.
There are three models in the application: Wish, User and location. The following diagram shows how the models have been designed:
In order to define the requirements and rank their priority according to the scope of the project, the group decided to use MoSCoW Model. The priorities are defined as Must, should, could, won’t. The requirements of iWish has been defined as follows:
|Sign in with SSO||The user is able to sign in into the application with his/her Facebook account||Must|
|View wishes||The user is able to view his own wishes||Must|
|Add wish||The user is able to create a wish||Must|
|View Profile||The user is able to view his/her profile||Should|
|Follow friend||The user is able to search and add friends||Should|
|View friends’ wishlist||The user is able to view friends wishes||Should|
|View calendar||The user is able to view calendar, where events such as friends birthday are shown||Could|
|Reserve gift||The user should be able to reserve a gift on a friends wishlist, so other friends won’t buy the same gift.||Could|
|Add shared wish||The user is able to create a shared gift, which is a gift that can be shared by multiple friends.||Could|
|View activities||The user is able to see friends activities on the home screen i.g when they create a new wish.||Could|
|Settings||The user is able to customize his/her app in the settings.||Won’t|
The group defined that sign in, add wishes and view wishes are the backbone of the application and must be implemented in the first iteration. Since the iWish goal is to share wishes with friends, it was necessary to implement features such as adding friends, and see their list of wishes. Therefore the following requirements were defined as “Should”. The “Could” requirements would be implemented if the group had extra time, and finally the “Won’t” requirements are defined as out of scope for this project.
In this section, the important design choices of the project will be described.
External libraries and frameworks
Currently the project is using two external libraries. The first library is Facebook’s iOS Login SDK. It was decided that iWish users must use their Facebook accounts to sign in and get access to all the features of the application. The first time a user is logging into the application with their Facebook credentials, they are asked to give permission so iWish can access data about their public profile and their email addresses. These information are needed, because the app needs basic information about the user in order to create a customized experience for the user. For example the user has his/her own profile, so it was necessary to fetch user data from a social media. Also when following friends, the user has to type their friend’s email address to follow the person, so the email is also fetched from their Facebook profile. The birthday and age of the user is also displayed on the user’s profile. However this is hardcoded into the View, because the group needs a lot of permissions and register papers on the Facebook Developer site in order to get access to that end-point.
Google’s Firebase platform has been used as the backend server. Two services are used from Firebase: Firebase Realtime Database and Firebase Cloud Storage. Firebase Realtime Database is used to store users, user information and their wishes, and Firebase Cloud Storage is used to store images. It was necessary to use a technology like a cloud-based backend solution in order to persist data, because the user needs to be able to share data with each other. The whole purpose with the app is to share wishes, and since the group has previous experience with Firebase, it was chosen as the backend solution. Core data as a offline data persistence solution has been discussed as well, but was decided to be out of scope for this project.
Finally Core Location and MapKit provided by the Apple Developer team has been used to get the user’s geographic location, and show it on the map. The framework gets the location data of a device using all available sensors and components on the device such as WiFi, GPS, Bluetooth etc. These libraries were necessary to use in order to show the location of where to buy a gift on a map.
In this section different parts of the implementation will be described.
There are two managers defined in the program. The UserManager and the WishManager. Both of them are designed as Singletons, because their instantiation should be restricted to a single instance. The WishManager manages the list of the current users wishes, and the UserManager holds all the information about the user:
TableView was the obvious choice when it comes to displaying users wishes, as well as user friends and their wishes. The code below shows how it was implemented.
The most important part here is that tableView using two constants. One that defines cell itself and one which defines wish object on specific row in TableView.
The most interesting fact is that the TableViewCell in WishTableView as well as FriendWishTableView using the same ViewController to display the content of an wish when it is selected. It could be done because of the segue. Segue can be used to transition between two ViewControllers and it was fitting perfectly in this situation. The code snit below shows how it was implemented inside MyWishes ViewControllers.
The addWish controller consists of features to create a wish locally, and uploading it to Firebase. As previously mentioned, the wish consist of title, description, price, location (optionally) and image (optionally). The method gets called when the addWish-handler is triggered by the user. First it is checked whether the users location has been set, since it is an optional.
Thereafter another function called addWishToDatabase is being called. This function calls Firebase in order to generate a unique ID for the wish. As you can see on the following code-snippet, it looks on a node called users, where it looks up the current user’s ID in the usermanager, then goes into his/her wishes and creates a child-node where its ID is generated. This is the unique key of the wish.
Firebase Realtime Database is a No-SQL database, and is tree-structured with key-value pairs as nodes. This is how the database has been designed:
As previously mentioned, the image is being store in Firebase Storage. The Realtime database holds a URL where the image can be downloaded. When the wish gets created and the ID gets generated, it is the same ID for the wish which is used as the filename to save the image in the Firebase Storage:
Here is how the files are stored in the Firebase Storage with the wish-ID as the filename:
Finally the wish is locally stored in the WishManager (again with the Firebase wish-ID as the unique ID:
This section will describe the results of the development.
The “Login” and “Home” screen was implemented as expected. The Facebook login button was implemented. Other social logins like Google, Twitter etc. are planned for future work. The Home screen does not contain anything interesting yet, but welcoming the user:
The “My wishes” and “Add Wish” screens were implemented as expected. Small UI elements differ from the final prototype. For example the group thought showing the price on the list of wishes was appropriate. Also a plus button in the navigation was a better way of showing how to add new wishes:
The “Profile” view was not as easy to implement that the group expected. As mentioned earlier the birthday is hardcoded due to issues with the Facebook API. Due to lack of time the list of friends has been shown on a table view of emails instead of showing the profile pictures in a collection view:
If a friend’s email is clicked, the user is redirected to the friends list of wishes. Here it is possible to click on a wish to see more information about the wish. For example a map of where it can be found:
In the following video you can see a demonstration of how the game works:
The source code for this application can be found on following links:
Bit Bucket: https://bitbucket.org/Jebisan/iwish/src/master/
Generally the group is satisfied with the obtained result from the development process. First of all, the group managed to implement all the critical requirements and base functionalities. The application uses multiple views, controllers and UI elements, and uses the MVC design pattern. Additionally the group managed to make use of multiple sensors, and three different TableViews are implemented. Finally the app makes use of external libraries and frameworks.
The group has used a lot of time preparing for the final demonstration of the app. Therefore the group has not used enough time writing clean code, and therefore the code needs a lot of refactoring in order to increase the readability and reusability. As the app is getting more and more complex, it is necessary to consider the refactoring as soon as possible if future development is considered.
In order to make user tests, iWish were tested on a number of students. The idea was received with positive feedback. The app got high credit for its user friendly interface and light design. The testers were positive surprised of how the app was working like a social media, where you can follow friends etc. Even more ideas on how to improve and add functionalities were obtained during the tests.
Even if the group obtained the important requirements of the app, there are still some features missing. First of all, there is no way to delete or edit a user’s wishes. This was also noticed by the users who tested the app. The testers also noticed that some way of adding priority to their wishes could be nice to have in the further development of the application. There are also unfinished tasks like getting the Facebook API for the users birthday in order to display the user’s real birthday and age on their profile. Also small bugs needs to be fixed. For example letting already logged in users to stay logged in, so they do not have to sign in every time they use the app.
The app also lacks a way to use the Home screen in a meaningful way. However it is planned to use the home screen to show friends’ activities. For example it could be used to show the the friends’ newest wishes like a social media showing new updates.
Generally implementing the “Could” requirements could make the app feel more complete and extraordinary than the already existing solutions.
In conclusion, the iWish project has been successful. The group managed to implement all the objectives within project scope and even more. Even if there are still space for improvements, the application at its current stage, could be used by the end users. However it is planned to continue working on the project, and make a final release on the App Store.