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 15:54:00 -0500
This is separate from my model. This is the restoration of the view and controller hierarchy that is expected of iPhone apps when they startup. Restoring this can be incredibly complex when you have lots of view controllers including nav controllers, tab bar controllers, and modal controllers all stacked up.
All of these are NSCoding compliant, which means that if I archive it, I should be able to unarchive it and get the exact state back (subject to conditional archiving, etc...) as long as I archive a complete object graph.
Clearly, if there are any connections in your nib that connect to proxy objects (or the file's owner), you'd have to restore them yourself since you aren't loading from the nib.
Storing the version of the app that saved the hierarchy would solve any issues related to that.
Note, I've written tons of code to manually restore the hierarchy for other apps, I'm just trying to be clever and to save myself a bunch of complex coding (that easily gets out of sync with how your hierarchies can be stacked) this time... :)
Jason
On Feb 10, 2010, at 3:12 PM, Jens Alfke wrote:
>
> On Feb 10, 2010, at 10:40 AM, Jason Bobier wrote:
>
>> 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)
>
> There's more to nib loading than just unarchiving views. I don't think this is unlikely to work.
>
> I don't think it should be necessary, either: it's a violation of MVC. The persistent data is the model; that's what you want to save. The views are configured at runtime to reflect the state of the model.
>
> One practical problem with your approach would be if you ever change the design of your view hierarchy in a future release. Now you have a complex schema-migration problem when existing users launch the new version of the app and load an obsolete view hierarchy.
>
> —Jens
_______________________________________________
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