There are three places where you have to think about state preservation in your app:
Your app delegate object, which manages the app’s top-level state
Your app’s view controller objects, which manage the overall state for your app’s user interface
Your app’s custom views, which might have some custom data that needs to be preserved
During preservation, your app is responsible for:
Telling UIKit that it supports state preservation.
Telling UIKit which view controllers and views should be preserved.
Encoding relevant data for any preserved objects.
During restoration, your app is responsible for:
Telling UIKit that it supports state restoration.
Providing (or creating) the objects that are requested by UIKit.
Decoding the state of your preserved objects and using it to return the object to its previous state.
UIKit preserves only those objects that have a restoration identifier. A restoration identifier is a string that identifies the view or view controller to UIKit and your app.
During the preservation process, UIKit walks your app’s view controller hierarchy and preserves all objects that have a restoration identifier.
For each view controller you choose to preserve, you also need to decide on how you want to restore it later. UIKit offers two ways to recreate objects. You can let your app delegate recreate it or you can assign a restoration class to the view controller and let that class recreate it. A restoration class implements theUIViewControllerRestoration
protocol and is responsible for finding or creating a designated object at restore time:
If the view controller is always loaded from your app’s main storyboard file at launch time, do not assign a restoration class. Instead, let your app delegate find the object or take advantage of UIKit’s support for implicitly finding restored objects.
For view controllers that are not loaded from your main storyboard file at launch time, assign a restoration class. The simplest option is to make each view controller its own restoration class.
Your app must have an Info.plist
file. This file contains information that the system needs to interact with your app. Xcode creates a version of this file automatically but most apps need to modify this file in some way.
Your app’s Info.plist
file must include the UIRequiredDeviceCapabilities
key. The App Store uses this key to determine whether or not a user can run your app on a specific device.
You must include one or more icons in your app bundle. The system uses these icons when presenting your app on the device’s home screen.
Your app must include at least one image to be displayed while your app is launching. The system displays this image to provide the user with immediate feedback that your app is launching.
Icon Dimension for iOS 7 & iOS 6 devices --- Table 5-2 & 5-3
Regardless of how many different icons your app has, you specify them using theCFBundleIcons
key in the Info.plist
file. The value of that key is an array of strings, each of which contains the filename of one of your icons. The filenames can be anything you want, but all image files must be in the PNG format and must reside in the top level of your app bundle. (Avoid using interlaced PNGs.) When the system needs an icon, it choose the image file whose size most closely matches the intended usage.
For apps that run on devices with Retina displays, two versions of each icon should be provided, with the second one being a high-resolution version of the original. The names of the two icons should be the same except for the inclusion of the string@2x
in the filename of the high-resolution image.
Every app must provide at least one launch image. This image is typically in a file namedDefault.png
that displays your app’s initial screen in a portrait orientation.
Use Asset Catelog to manage App Icon & Launch Images --- Xcode Overview
Preferences and Settings Programming Guide.
Locate the resource.
Load the resource.
Use the resource.
NSBundle
object. A bundle object understands the structure of your app’s bundle and knows how to locate resources inside it. Bundle objects even use the current language settings to choose an appropriately localized version of the resource. The
pathForResource:ofType:
method is one of several
NSBundle
methods that you can use to retrieve the location of resource files.
Once you have the location of a resource file, you have to decide the most appropriate way to load it into memory. Common resource types usually have a corresponding class that you use to load the resource:
To load view controllers (and their corresponding views) from a storyboard, use theUIStoryboard
class.
To load an image, use the methods of the UIImage
class.
To load string resources, use the NSLocalizedString
and related macros defined in Foundation framework.
To load the contents of a property list, use the dictionaryWithContentsOfURL:
method of NSDictionary
, or use the NSPropertyListSerialization
class.
To load binary data files, use the methods of the NSData
class.
To load audio and video resources, use the classes of the Assets Library, Media Player, or AV Foundation frameworks.
NSString* imagePath = [[NSBundle mainBundle] pathForResource:@"sun" ofType:@"png"];
UIImage* sunImage = [[UIImage alloc] initWithContentsOfFile:imagePath];