Re: Mixing UIDocument's NSUndoManager and -updateChangeCount:
Re: Mixing UIDocument's NSUndoManager and -updateChangeCount:
- Subject: Re: Mixing UIDocument's NSUndoManager and -updateChangeCount:
- From: Kyle Sluder <email@hidden>
- Date: Mon, 13 Jan 2014 08:29:37 -0800
On Mon, Jan 13, 2014, at 07:21 AM, Markus Spoettl wrote:
> Hi,
>
> I have an app that uses UIDocument and NSUndoManager. That way the
> system
> picks up changes to the data and knows when to auto-save.
>
> Some parts of the model are not using the undo manager (mostly settings
> where
> undo makes no sense or isn't wanted). Still that data is stored alongside
> the
> main data.
>
> What I want is that iOS saves whenever the app is backgrounded.
>
> So the questions is: Can I safely call -updateChangeCount: when my app is
> being
> sent to the background alongside the automatic NSUndoManager change
> handling?
>
> It seems to work quite nicely (when called from the app delegate's
> -applicationWillResignActive:), but I'm not sure if that's just an
> illusion and
> there's trouble waiting down the road.
>
> Any thoughts?
This does not strike me as a good idea. -updateChangeCount: is a
counter; adding a place that increments the counter without having a
corresponding decrement sounds like an invitation for state corruption,
particularly in the presence of framework code that treats the counter
as normal.
It would be better to add a flag to your UIDocument subclass that you
set whenever the user changes a non-undoable model property, and
override -hasUnsavedChanges to return the OR of this property and
super's return value.
--Kyle Sluder
_______________________________________________
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