Re: Using NSKeyedArchiver to save and restore state on iPhone apps
Re: Using NSKeyedArchiver to save and restore state on iPhone apps
- Subject: Re: Using NSKeyedArchiver to save and restore state on iPhone apps
- From: Ricky Sharp <email@hidden>
- Date: Wed, 10 Feb 2010 15:53:29 -0600
On Feb 10, 2010, at 12:40 PM, Jason Bobier wrote:
> As many of you know, saving and restoring complex navigation hierarchies on the iPhone can be a real chore. So, I had this brilliant idea of setting up my app delegate like this:
>
> applicationDidFinishLaunching
> if userdefaults contains an archived navcontroller
> unarchive controller and retain
> else
> load nib with controller and retain
> add navcontroller view to window
>
> applicationWillTerminate
> archive nav controller and save to user defaults
>
> and then make all of my view controllers NSCoding compliant
>
> In theory, the archived navcontroller should contain my complex view controller hierarchy and all of the related views, so this should work.
>
> However, when I unarchive and add to view to the window, the subviews rarely have all of their values set correctly despite being supposedly NSCoding compliant. (For example, I have a button that fails to have it's target and action set)
>
> Am I missing something here or is this just buggy NSCoding compliant code on apple's part?
You don't want to take this approach at all.
The proper thing to do is to archive model data (as others have pointed out). Note that this will now also be faster too since it will be a much smaller data set.
For nav-based apps, this set of data often includes a "screen ID" of what screen the user left off at. Upon app launch, you can basically just push whatever screen you need to on the nav controller's stack.
This is exactly what I do in my own iPhone OS apps. I also have an infrastructure to pass an NSDictionary filled with parameters as users hop from screen to screen.
This allowed me to do stuff like this:
In MyScreenA...
- (IBAction)someAction:(id)sender
{
NSDictionary* = parameters = ...;
[self pushScreen:MyScreenBID withParameters:parameters animated:YES];
}
If users exit the app while on Screen B, I simply store the fact that I was on that screen (and any other metadata I need to preserve selections, scroll position, etc.)
Then, on app launch, if such a freeze-dried state exists, I ultimately build up a set of parameters just like I did in the action method above. Then push the appropriate screen with those parameters (and set animated flag to NO). This will give the appearance of the app launching directly to the screen the user left off.
But, under the covers, this is what actually occurs on app launch:
- app launch routines
- nav controller created; main nib loaded and set as top view
- code that senses you have a saved state
- push appropriate view controller to go to last used screen
All the standard nib-loading occurs and things just work.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden