Every iOS application has its own application sandbox. An application sandbox is a directory on the filesystem that is barricaded from the rest of the filesystem. Your application must stay in its sandbox, and no other application can access its sandbox. Figure 13.3 shows an example application sandbox.
The application sandbox contains a number of directories:
- Documents/
-
This directory is where you write data that the application generates during runtime and that you want to persist between runs of the application. It is backed up when the device is synchronized with iCloud or Finder. If something goes wrong with the device, files in this directory can be restored from iCloud or Finder. In LootLogger, the file that holds the data for all your items will be stored here.
- Library/Caches/
-
This directory is where you write data that the application generates during runtime and that you want to persist between runs of the application. However, unlike the Documents directory, it does not get backed up when the device is synchronized with iCloud or Finder. A major reason for not backing up cached data is that the data can be very large and extend the time it takes to synchronize your device. Data stored somewhere else – like a web server – can be placed in this directory. If the user needs to restore the device, this data can be downloaded from the web server again. If the device is very low on disk space, the system may delete the contents of this directory.
- Library/Preferences/
-
This directory is where any preferences are stored and where the Settings application looks for application preferences. Library/Preferences is handled automatically by the class UserDefaults and is backed up when the device is synchronized with iCloud or Finder.
- tmp/
-
This directory is where you write data that you will use temporarily during an application’s runtime. The OS may purge files in this directory when your application is not running. However, to be tidy you should explicitly remove files from this directory when you no longer need them. This directory does not get backed up when the device is synchronized with iCloud or Finder.
The instances of Item from LootLogger will be saved to a single file in the Documents/ directory. The ItemStore will handle writing to and reading from that file. To do this, the ItemStore needs to construct a URL to this file.
Implement a new property in ItemStore.swift to store this URL.
Listing 13.6 Adding the URL that items will be saved to (ItemStore.swift)
var allItems = [Item]()
let itemArchiveURL: URL = {
let documentsDirectories =
FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)
let documentDirectory = documentsDirectories.first!
return documentDirectory.appendingPathComponent("items.plist")
}()
Instead of assigning a value to the property directly, the value is being set using a closure. You may recall that you did this with the numberFormatter property in Chapter 6. Notice that the closure here has a signature of () -> URL, meaning it does not take in any arguments and it returns an instance of URL.
When the ItemStore class is instantiated, this closure will be run and the return value will be assigned to the itemArchiveURL property. Using a closure like this allows you to set the value for a variable or constant that requires multiple lines of code, which can be very useful when configuring objects. This makes your code more maintainable because it keeps the property and the code needed to generate the property together.
The method urls(for:in:) searches the filesystem for a URL that meets the criteria given by the arguments.
In iOS, the last argument is always the same. (This method is borrowed from macOS, where there are significantly more options.) The first argument is a SearchPathDirectory enumeration that specifies the directory in the sandbox you want the URL for. For example, searching for .cachesDirectory will return the Caches directory in the application’s sandbox. Double-check that your first argument is .documentDirectory and not .documentationDirectory. It is easy to introduce this error and end up with the wrong URL.
You can search the documentation for SearchPathDirectory to locate the other options. Remember that these enumeration values are shared by iOS and macOS, so not all of them will work on iOS.
The return value of urls(for:in:) is an array of URLs. It is an array because in macOS there may be multiple URLs that meet the search criteria. In iOS, however, there will only be one (if the directory you searched for is an appropriate sandbox directory). Therefore, the name of the archive file is appended to the first and only URL in the array. This will be where the archive of Item instances will live.
You now have a place to save data on the filesystem and a model object that can be saved to the filesystem. The final two questions are: When do you write the data to disk, and how? To answer the first of these questions, you need to understand the lifecycle of iOS scenes.