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: Jason Bobier <email@hidden>
- Date: Wed, 10 Feb 2010 19:38:10 -0500
Hey Ricky,
I'm strictly attempting to archive the controllers and views hierarchy starting from the navcontroller. My data model is quite separate from all of this.
I've often done similar things to what you recommend, but complex interfaces often include tab controllers, nav controllers, modal views, etc..., storing the precise order of all of these along with the related metadata of all of the controls is a pain and prone to error.
This idea came about because I was annoyed at having to do it again and realized that everything that I wanted to store was NSCoding compliant, which means that it should be archivable. It appears that some of the NSCoding compliant objects aren't completely restorable tho. :-/
Jason
On Feb 10, 2010, at 4:53 PM, Ricky Sharp wrote:
>
> On Feb 10, 2010, at 12:40 PM, Jason Bobier wrote:
>
> 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