developed by
kaspc14 & mmare15

png files used in the application :
The code can be found here:


The application is a game where it is the player’s goal to place items on the map and find items that have been placed on the map. The player walks around in the real world and has a map showing his/her location in realtime. When the player approaches the location of an item placed on the map, he/she will collect it and it will be visible in the section of the app dedicated to viewing the items.

This is a scaled down version of the original idea presented in the frist hand-in. The reason for the scale-down was primarily based on feedback from other  groups when discussing the workload involved.


The following methods have been used during the development of the application.


The first method used in the group was the brainstorming method, this method enables the group to potentially have a variety of application topics at hand. Based on the result in the Brainstorm we weighted the options in terms of foreseeability and further development options.


Use Case 

In the process of identifying exactly what the application should be capable of doing, use case diagrams was developed to have a representation of the user’s interaction with the system that we were developing.

the following use case diagram represent the uses for user in this iteration of the game.


Conceptual design

The use cases allowed for us to easily identify the necessary screens, since both are rooted in the user’s point of view. Agreeing on all the screens, we could begin to conceptualise an actual design which was realised using Marvel:


The process of developing the conceptual design benefited the developing process by giving an estimate about the number of views available to the user.

User testing and feedback

Multiple users were involved with the user testing process. The feedback would allow for us to revisit our design and also change focus points to the more urging aspects.
This also lead to a reevaluation of the time estimate, which ended in a decision to revisit the use case diagram to make sure the de-scaled version was properly documented.


The implementation process has been a challenge due to difficulties handling multiple users location data, storing the information on a database and allowing multiple users to sign in.

The implementation have been properly scaled to the amount of members capable of developing on the application and the time and skills.
The application functionality is now acting as a of proof of concept for the original idea.

Due to the core use of location usage and savings, the following frameworks where chosen for implementation:

  • MapKit
    • The application uses the MapKit framework to display a satellite view for the players current.
  • Firebase/GeoFire
    • The application uses the Firebase framework to save and retrieve geo-based data.
    • reference Geofire:
    • reference Firebase:



Following is the key results from the relevant methods described above.
Please note that the first time the application run it will not function and needs to close the simulation and open it again.


The implementation is heavily influenced by our second phase’s feedback results, but the key idea to use location services still holds through the chosen frameworks.

The code below is from the MapViewController class, and follows the convention described in the documentation from
and is used for adding an observer to our GeoFire query, which will then execute the code inside each time a key from the database enters within the set radius of the user.

let center = mapView.userLocation.location!
            self.circleQuery = geoFire.query(at: center, withRadius: 0.200)

            circleQuery.observe(.keyEntered, with: { (key: String!,  location: CLLocation!) in

                let itemAnnotation = MKPointAnnotation()
                itemAnnotation.coordinate = location.coordinate

                let keyInt = Int(key)!
                var found = false
                for item in self.itemsForView {
                    if item.itemId == keyInt {
                        found = true
                if !found {
                    self.itemsForView.append(Item(coordinate: location.coordinate, itemId: keyInt))


Much of the framework code follows the documentation’s setup with a few of our own specific implementations.
The ItemTableViewController and its corresponding Cell where implemented following the example from Apple:…

In order to divide the architecture into following the MVC pattern, the DBConnection class has been created, but not yet implemented. It would handle all the responsibility regarding connection to the database, and so it would be the only class to import the Firebase module. As the model, it would then notify the controller of any updates regarding the items to view (which the controller would then tell the view to display), as this is a changing event based on the user’s location.

In order to simulate walking, a .gpx file was downloaded from whereafter the timestamps for the first minute of coordinates was altered to simulate faster walking. The file is located within the project structure: ItemSearch/ItemSearch/firstTry.gpx.



The results in the final application does deliver on multiple parameters of the initial application. The application can track the player and the user can throw an item where he is located. The application does provide support for the user to see items thrown in the item by the player or by other users near. It is good that the application delivers on the use cases for the system, but the way it is presented to the users and with some application issues makes room for improvements in this aspect in the next iteration of the application.

The user evaluation has played a key aspect of the development of the application, it was this evaluation that made us reevaluate the development process and focus on an application that focuses on placing items on a map.

Leave a Reply