As mentioned in my ‘Everyone Starts Somewhere’ post, one of the things that needed improving for my Lord of the Rings quiz was how the database of questions were stored.
To do this, I think it’s worth diving a little deeper into how in the current app works, what improvements Ben suggested to make a more realistic ‘consumer’ app, and then what we did next.
Files
When I created the Lord of the Rings quiz, I was learning a lot of things for the very first time.
What this meant is that a lot of functionality of the app is pieced together and inevitably not what would be deemed ‘best practice’.
In it’s simplest form, the app starts with an array of all the questions that are available to be answered, these questions are hardcoded into the app itself (a file 542 lines long I might add) and created on initialisation of the app.
Once the user begins the quiz and a question is presented to them, the selected question is removed from the full database of questions, and appended into a new array for used questions.
When learning how to persist this information the solution I came across was to encode the array into a .json file, and save that file directly to the users’ Files app on their device… I didn't say it was elegant 😆.
The code snippet below shows how the app currently handles saving of the ‘allQuestions’ array:
The same applies to the reading of these files so that the app can find out a users’ progression but instead of encoding, the app decodes the files from the Files app, and then reads the .json files.
I have included a few screenshots below to give you an example of how this all looks on device. If you have the LotR Quiz installed on your own device, this will all be present in your Files app, so you can take a look for yourself!
The Files app with the database for ‘LotR Quiz’
As mentioned this is definitely not the most elegant solution to persisting data and there are many flaws with doing it this way, some that come to mind:
There is no option for backing the data up, therefore if a user loses their files, get’s a new device, or plain deletes the files, then they lose all their progress.
iCloud sync options for multiple devices is limited, and the user is restricted in using only the device they initially downloaded the app on.
Lastly if the user does not allow permissions for the app to access the devices’ Files app, then persistence just plain won’t work.
What Happened Next?
The ethos for the project is to always try and make it as replicable of a real-world scenario as possible, and the above current solution is not a realistic ‘commercial’ way to persist data.
Therefore, during our initial discussions on the project Ben suggested that we used some form of database service.
We looked at a couple of options, and narrowed it down to the two Google offerings. This consisted of using either Google’s latest database called ‘Cloud Firestore’, or the more familiar database of ‘Realtime Database’.
Ultimately we settled on using the Realtime Database option for a few reasons; firstly it was something we’d both had at least some familiarity with just not specifically the database module, so we’d learn something there, second it was something we could easily implement using Swift Package Manager (again, another learning for us both) and lastly Firebase being relatively popular as a database service with other companies.
You can find out all the information you need on both databases, including the benefits of using one over the other here if you’re considering them as database solutions.
There are plenty of free tiers that supported our requirements and so we promptly created our Firebase account and integrated it with our Xcode project using Swift Package Manager (more on SPM in a later post) and then got to work on creating our database.
Firebase makes it very easy for you to import a .json file into your database and therefore we created our .json file and imported them directly into the database via the Firebase console.
And that was it! The database now lives in the cloud on some servers somewhere in the United States rather than on your Files app on device 😄.
In a subsequent post I will explore the steps of reading the database from the Xcode project and what service we decided to use on persisting data locally on device for situations where a network may not be an option.
Thanks again for reading, I hope you enjoyed reading more about the project! Don’t forget to follow the project on GitHub also by using this link.
