Application Sandbox

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 16.3 shows the application sandbox for iTunes/iCloud.

Figure 16.3  Application sandbox

Screenshot shows the application sandbox for iTunes/iCloud.

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 iTunes or iCloud. If something goes wrong with the device, files in this directory can be restored from iTunes or iCloud. In Homepwner, 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 iTunes or iCloud. 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 NSUserDefaults and is backed up when the device is synchronized with iTunes or iCloud.

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 iTunes or iCloud.

Constructing a file URL

The instances of Item from Homepwner 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.

var allItems = [Item]()
let itemArchiveURL: URL = {
    let documentsDirectories =
        FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)
    let documentDirectory = documentsDirectories.first!
    return documentDirectory.appendingPathComponent("items.archive")
}()

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 4. 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. (Double-check that your first argument is .documentDirectory and not .documentationDirectory. Autocomplete’s first suggestion is .documentationDirectory, so it is easy to introduce this error and end up with the wrong URL.)

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.

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset