BitBucket link:

Group members: Martin Sørensen, Martin Lykke, Borgar bordoy


1.0 Introduction

Our app is called SDU groups and it is a tool which aims to ease the coordination within study groups by gathering different important group tools into one place. The tools gathered are aimed towards students at SDU.

The idea is to have an app which helps new and older students at SDU with various everyday tasks, easing the process of e.g. finding your group members on campus by location sharing or simply booking a room for your project group. By combining several functions into one app the student won’t need to open different applications to either see which people are in his group, book a room or see his own location in order to find the correct room.

SDU has a big campus in Odense which can make it very confusing for especially new students to locate the rooms they use for courses or group work. Furthermore if you want to book a room for group work or as a working space in general, it can be difficult to navigate through blackboard to book a room since blackboard has a lot of different functions. 

As a group we have worked together in different projects together before. A thought that came to our mind is that groups require a lot of different tools in order to have efficient group work with e.g. communication and file sharing. This resulted in the idea of creating an app helps users find the most essential tools for their work, combining it all into one app, either by implementing new features or simply redirecting the user to the correct web pages.

The importance of this topic comes from the fact that many students at SDU struggle with everyday activities which should be easy.

2.0 Methods and Materials

This section covers the materials and methods used to create SDU Groups.

2.1 Brainstorm

During the idea phase at the beginning of the project, the group brainstormed and had a bunch of ideas. This is how we decided what to create.

2.2 Conceptual Design

After picking our idea, we drew a quick conceptual design on a whiteboard. This gave a good idea of what the graphical user interface could look like.

2.3 Use case diagram

A use case was drawn in the early stages of the project in order to have a simple view of what  features the app would should have.

2.4 Methods

SDU-Groups has been developed with Swift and Xcode as it’s IDE. GitHub has been responsible for version control handling and the file sharing. Furthermore the application has implemented Firebase Storage as the database and Firebase Authentication for the security measurements of the users when signing and logging on.

3.0 Results

3.1 Brainstorm

The brainstorm resulted in the group agreeing on making the SDU Groups application, which then led to another brainstorm that resulted in us knowing which features the application could have.

3.2 Conceptual design

Figure 1 below shows the result of us working on a conceptual design.

Figure 1 – Concept drawing of GUI

The drawing visualizes the different screens that we wanted within the app, as well as basic GUI such as buttons and textfields.

3.3 Use case diagram

The figure below shows the result of our use-case diagram.

Figure 2 – Use Case from idea phase

The use case gives a basic view of what the user can should  be able to do, but not what is actually possible, since the use case was made before the actual implementation. The user should be able to see his current location, see the group contracts that has been signed by him, show which rooms he has booked, see his schedule, book a room and open settings.
These are the features which came from the brainstorming in the idea phase. After interviews and conversations with some professors and IT staff at SDU it was clear that our scope was big and developing some of these features would result in complications. An example of a complication would be complying with GDPR when handling the data which concerns a users location.

3.4 Firestore

Firestore is a widely used mobile and web development platform. The group has chosen to integration two of firestores products in the application. This way we are able to develop a much better product and not having to spend a lot of time on creating features from scratch.

3.5 Authentication

The first Firestore product is their authentication module. We use this as a security measure so that people will have to sign in to use our application. Firestore authenticate users by integration with federated identity providers. This means that the users are able to sign in with their Facebook, Google, Github etc. accounts. Figure 3 shows how new users are saved in the database hosted by Firestore.

Figure 3 – Firebase Authentication

It shows identifier for the user which is their email. We are also able to see when a user is created and the last time they signed in. An unique user ID is auto generated.

3.6 Database

We also use Firestore database module. It is a realtime database, which means that application data can be synchronized across clients. We use it for storing users and files, such as a group contract. In figure 4 we can see how a contract is connected to a group. The contact has a field for the actual group contract and a field for the user who made it.

Figure 4 – SDU Groups Firebase Database

3.7 CocoaPods

We use a podfile to install the Firebase dependencies as shown in figure 5. Usage of Podfiles is a smart way to install frameworks and keep them updated.

Figure 5 – Podfile

3.8 LoginViewController

The LoginViewController is the controller for the first view that the user sees when launching the application. Within this file there is a method called loginTapped which contains the logic that handles the authentication after a user attempts to log in. The method sets two variables to the text inputted by the user in the textfields, then calls the auth().signIn method from Firebase. The Auth() method takes the two mentioned variables as parameter, and if error is not Nil, then transitionToHome() is called. This method then changes the view.

Figure 6 – Code from LoginViewController

3.9 MapViewController

When the user opens the map tab, the application asks for permission to use the device’s location. Figure 7 shows a method called checkLocationAuthorization() which contains a switch statement with different cases depending on whether the user granted the application permission or not. If CLLocationManager.authorizationStatus() returns “authorizedWhenInUse” then the user has granted the app permission and his location will be shown on the map.

Figure 7 – Code from MapViewController

We faced a lot of trouble implementing a rooms location on the map. At the beginning of the project we wanted to use SDU Maps to pinpoint a booked room on our map. After having a meeting with IT Staff at SDUfor getting access to SDU Maps, we learned that it was not really possible. Actually SDU Maps is the only app/API which defined a rooms location on the map. Therefore we chose to hardcode a map pinpoint to show how it could have worked.

Figure 8 – Point on map

3.91 GroupViewController

The GroupViewController contains the logic for the schedule and room booking features. As mentioned in the earlier sections, the project scope was deemed rather big, therefore we chose to have the buttons for these two features simply redirect the user to relevant pages within SDU’s domain. The solution for these two features is temporary.

Figure 9 – Code from GroupViewController

4.0 Discussion

4.1 Our results

The idea phase secured us a great idea but also led to too many features of which some turned out to be rather challenging. The current version servers as a good foundation for a future complete application which includes all mentioned features. The group’s main objective was to fulfill the requirements for the project and it has been succeeded by usage of the users GPS and by creating this post.

4.2 Future features

As mentioned in previous sections there are features which still need to be implemented in order for us to deem the app complete. These features include creating a group within the app which the user can invite other students to join. The members of the group should then be able to share their location with each other.

The app also needs to output error messages to the user in form of prompts in the GUI whenever the user e.g. does something wrong, like entering an incorrect password.

4.3 Rivals

The biggest competitor to this app would be SDU Maps, however this app does not aim to offer the same services, since attempting to compete with SDU Maps would be ridiculously hard. The group believes that there is no app with the same concept at this one.

4.4 Conclusion

All group members have gained a lot of experience regarding creating applications in xcode with swift. It can be concluded that the project was successful in fulfilling requirements for the IOS course and that the project serves as a solid foundation for an application which could be further developed later on.

4.5 Perspective

The project would be continued by implementing the rest of the features and then letting students test the application which would lead to useful feedback.

Leave a Reply