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:rsh...@instantinteractive.com
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
