State Restoration with NSDocument architecture
Hi all- I’m working on a document-based app and making every effort to adopt the behaviors of a modern app. This includes state restoration, described in the current documentation at: https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html#//apple_ref/doc/uid/TP40010543-CH3-SW14 Despite my best efforts, I’m not having any success with any actual “restoration”… I’ve never seen any evidence of the system attempting to call the relevant overrides when launching my app, after leaving documents open during a quit or log out. Here’s what I know: - document windows have a restoration identifier. - document windows are set to be restorable. - document windows are confirmed to have a restoration class of my custom NSDocumenController subclass (made solely to catch the calling of restoreWindowWithIdentifier:state:completionHandler:). If I don’t subclass, they are confirmed to have a restoration class of NSDocumentController. - I’ve adopted automatic termination by setting the correct Info.plist entry. What works: I can see encodeRestorableStateWithCoder: being called on my window and on view subclasses that I want to restore state for. What does not work: I never see a corresponding restoreStateWithCoder: get called on the window or views, nor do any of the NSWindowRestoration overrides get called… no restoreWindowWithIdentifier:state:completionHandler: on custom NSDocumentController no restoreDocumentWindowWithIdentifier:state:completionHandler: on custom NSDocument I’ve Googled extensively; there’s so little on the topic that I’m wondering if developers are actively adopting this feature. Does anyone have an app that works properly with state restoration, or have a few snippets or ideas to share? Any help is much appreciated - thanks! John ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: State Restoration with NSDocument architecture
On May 24, 2014, at 6:44 AM, John Pannell wrote: > I’m working on a document-based app and making every effort to adopt the > behaviors of a modern app. This includes state restoration, described in the > current documentation at: > > https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html#//apple_ref/doc/uid/TP40010543-CH3-SW14 This doc is better, although may not address your concerns entirely: https://developer.apple.com/library/mac/documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/StandardBehaviors/StandardBehaviors.html#//apple_ref/doc/uid/TP40011179-CH5-SW8 I have restore/auto-save working, and it was a relatively painless process. You might be over-thinking it a little--document-based apps get restoration support automagically as long as windows are marked restorable. That's pretty much it. The standard load/save methods will be called when needed, and you don't need to conserve yourself with any other part of restoration unless you need to explicitly maintain state that is not part of the document proper (generally). As a suggestion, I would start with the built-in behavior before you start overriding things, so at least you are proceeding from a working state. > Despite my best efforts, I’m not having any success with any actual > “restoration”… I’ve never seen any evidence of the system attempting to call > the relevant overrides when launching my app, after leaving documents open > during a quit or log out. Here’s what I know: > > - document windows have a restoration identifier. You don't have to specify this, unless you specifically need to reference it in your own code. > - document windows are set to be restorable. Good. > - document windows are confirmed to have a restoration class of my custom > NSDocumenController subclass (made solely to catch the calling of > restoreWindowWithIdentifier:state:completionHandler:). If I don’t subclass, > they are confirmed to have a restoration class of NSDocumentController. Pointless. This is all done automatically. Remove the code as you could be getting in the way. > - I’ve adopted automatic termination by setting the correct Info.plist entry. Do you mean NSSupportsAutomaticTermination? That is related to restoration but tangential although won't effect restoration behavior so it doesn't matter at the moment. > What works: > > I can see encodeRestorableStateWithCoder: being called on my window and on > view subclasses that I want to restore state for. This will only happen when the API thinks it needs to, and not necessarily (or typically) when you quit your app. I ran across this issue and I don't think it is properly documented. I.e., if the API doesn't believe that you state has changed since the window was opened, it won't save the state. If you use autosave, it will save state when the document autosaves, but you can run into a timing issue where changes to state that are made just after an autosave won't save. So the rule of thumb is use is, if it is part of the document I either register undo or force the dirty state of the document so a save will be forced; for everything else I always send -invalidateRetsorableState to the window every time I make a state change. Lastly, although it may be obvious, the "restore windows" system setting must be turned on, or you have to use the option-quit method. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Unwanted Animations
Two separate issues: 1. CALayer Animation. I have a movie sublayer which has an observer to track an underlying draw object¹s bounds. When dragging the object, the movie layer position lags. I¹ve tried ³removeAnimationForKey:@²position², and ³removeAllAnimations² when creating the layer. I¹ve also tried the latter, and ³[superlayer removeAllAnimations]² in the observer. Nothing works. How do I kill that animation? 2. Toolbar animation. I have a window, sometimes used for screen capture. When the user toggles the toolbar, I readjust the window position to keep its content within the set capture rect. (Changing the capture rect will kill any recording.) It works, but the toolbar animates, then jerks to the correct position. Is there any way to kill toolbar animation? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unwanted Animations
On May 24, 2014, at 10:02 AM, Gordon Apple wrote: > Two separate issues: > > 1. CALayer Animation. I have a movie sublayer which has an observer to > track an underlying draw object¹s bounds. When dragging the object, the > movie layer position lags. I¹ve tried ³removeAnimationForKey:@²position², > and ³removeAllAnimations² when creating the layer. I¹ve also tried the > latter, and ³[superlayer removeAllAnimations]² in the observer. Nothing > works. How do I kill that animation? For ways to kill it permanently for a given layer, see the docs on -[CALayer actionForKey:]. For one-off type disables, see -[CATransaction setDisableActions:] > 2. Toolbar animation. I have a window, sometimes used for screen capture. > When the user toggles the toolbar, I readjust the window position to keep > its content within the set capture rect. (Changing the capture rect will > kill any recording.) It works, but the toolbar animates, then jerks to the > correct position. Is there any way to kill toolbar animation? > > ___ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: State Restoration with NSDocument architecture
Hi Keary - I knew it was going to be something like this… :-) On May 24, 2014, at 8:58 AM, Keary Suska wrote: > Lastly, although it may be obvious, the "restore windows" system setting must > be turned on, or you have to use the option-quit method. Indeed - the setting was set to close windows upon quit, and prevent restore. Once fixed, everything started working as described. Thanks for your help - sometimes hearing the obvious is exactly what I need! John ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Understanding ARC
Dear Sir,
I'm trying to teach myself Objective C and I don't understand ARC very
well. Please could someone help me.
If I've understood this correctly (silly example):
-(NSString*)stringdoodad
{
NSMutableString* returnString = [[NSMutableString alloc] init];
@autoreleasepool
{
for (NSUInteger i = 0; i < 10; i++)
{
NSString* testString = @"hello";
[returnString appendString:testString];
}
}
return returnString;
}
In the example, everything inside the autoreleasepool block will be
released as soon as the block ends, so it's necessary to declare the return
value outside the block.
When does returnString get released? Does it get automatically released as
soon as the method ends and the value has been passed into whatever
container was waiting for it? Do I need to do anything special in order to
make sure that it is released as soon as it's done its job?
If it gets called by the following method:
-(void)stringDoodadCaller
{
@autoreleasepool
{
NSString* testString = [self stringdoodad];
}
}
Would returnString be released because stringdoodad is called within an
autoreleasepool?
I don't think I've understood Apple's documentation on this - have I got
this right or wrong?
Also, why is it that memory automatically gets released properly when an
application quits, but when a class is released any memory that hasn't been
freed or released properly hangs around forever?
Yours faithfully,
Jamie Ojomoh
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Understanding ARC
The compiler handles the case of a returned object properly. Ownership in the
form of one reference will pass, in your example, from returnString to
testString due to the assignment to the return value. testString will be
released when the block it’s in exits, and since there are no more referrers to
the NSString at that point, it will be cleaned up.
Also, it is not generally needed to manage autorelease pools yourself unless
you’re doing something more complicated. In the case of a Cocoa app, you will
always be in the context of an autorelease pool during any call into your code
from the run loop.
On May 24, 2014, at 2:34 PM, Jamie Ojomoh wrote:
> Dear Sir,
>
> I'm trying to teach myself Objective C and I don't understand ARC very
> well. Please could someone help me.
>
> If I've understood this correctly (silly example):
>
> -(NSString*)stringdoodad
> {
>NSMutableString* returnString = [[NSMutableString alloc] init];
>@autoreleasepool
>{
>for (NSUInteger i = 0; i < 10; i++)
>{
>NSString* testString = @"hello";
>[returnString appendString:testString];
>}
>}
>return returnString;
> }
>
> In the example, everything inside the autoreleasepool block will be
> released as soon as the block ends, so it's necessary to declare the return
> value outside the block.
>
> When does returnString get released? Does it get automatically released as
> soon as the method ends and the value has been passed into whatever
> container was waiting for it? Do I need to do anything special in order to
> make sure that it is released as soon as it's done its job?
>
> If it gets called by the following method:
>
> -(void)stringDoodadCaller
> {
>@autoreleasepool
>{
>NSString* testString = [self stringdoodad];
>}
> }
>
> Would returnString be released because stringdoodad is called within an
> autoreleasepool?
>
> I don't think I've understood Apple's documentation on this - have I got
> this right or wrong?
>
> Also, why is it that memory automatically gets released properly when an
> application quits, but when a class is released any memory that hasn't been
> freed or released properly hangs around forever?
>
> Yours faithfully,
>
> Jamie Ojomoh
> ___
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/velocityboy%40rodentia.net
>
> This email sent to velocity...@rodentia.net
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Understanding ARC
On May 24, 2014, at 2:34 PM, Jamie Ojomoh wrote: > In the example, everything inside the autoreleasepool block will be > released as soon as the block ends, so it's necessary to declare the return > value outside the block. No, in general ARC understands that the return value needs to keep a reference, so it’s safe to put the return statement inside the autorelease block. In your specific example, returnString was allocated before you created your autorelease pool, so that pool won’t release it anyway. Also, you allocated returnString using an alloc/init sequence so it’s not in an autorelease pool at all. (In your example I don’t think the autorelease pool is doing anything at all, since there are no calls in that block that would cause any object to be autoreleased.) > When does returnString get released? Does it get automatically released as > soon as the method ends and the value has been passed into whatever > container was waiting for it? I believe ARC will take care of autoreleasing it at the point where it’s returned. Apple’s docs specifically recommend that you _don’t_ worry about when objects are being retained or released. ARC basically takes care of it for you, so most of the time you can pretend that the app is garbage-collected and ignore retain/release entirely. Instead, consider where you need strong or weak references to objects; this is mostly a concern when declaring instance variables. —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
string literals and performance
Are there any performance implications that would suggest preferring one or the other of these different styles? NSString *s = @"sing me a song"; [myClass aMethod: s]; and [myClass aMethod: @"sing me a song"]; I have a lot of the first kind in my code, and I'm thinking of simplifying it by turning them all into the second kind. A discussion on stackoverflow here: http://stackoverflow.com/questions/25746/whats-the-difference-between-a-string-constant-and-a-string-literal seems to suggest (if I've understood it correctly) that I'd be better off sticking with the first style to avoid errors and to speed up comparisons. However, since in my code they're all one-off 'throw away" strings that don't get used elsewhere, that doesn't seem relevant. Is there any other reason why I should stick with the first style rather than the second? Thanks for your thoughts. P signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: string literals and performance
You misunderstand the point of the Stackoverflow answer. In the first example you've given it looks like "s" is just a stack local variable. In that case there is no difference between the two examples. Actually, in the face of optimization I bet the assembly turns out exactly the same. Use the later because it is more clear what's going on. If you did use the same string literal in multiple .m files then you might get a tiny performance benefit from the "extern NSString* const". But I'd argue that the real benefit to that is if you ever decide to change the value then you don't have to worry about updating multiple locations and/or projects (in the case of a framework). On Sat, May 24, 2014 at 11:08 PM, 2551 <2551p...@gmail.com> wrote: > Are there any performance implications that would suggest preferring one > or the other of these different styles? > > NSString *s = @"sing me a song"; > [myClass aMethod: s]; > > and > > [myClass aMethod: @"sing me a song"]; > > I have a lot of the first kind in my code, and I'm thinking of simplifying > it by turning them all into the second kind. A discussion on stackoverflow > here: > > > http://stackoverflow.com/questions/25746/whats-the-difference-between-a-string-constant-and-a-string-literal > > seems to suggest (if I've understood it correctly) that I'd be better off > sticking with the first style to avoid errors and to speed up comparisons. > However, since in my code they're all one-off 'throw away" strings that > don't get used elsewhere, that doesn't seem relevant. Is there any other > reason why I should stick with the first style rather than the second? > > > Thanks for your thoughts. > > P > > ___ > > 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: > > https://lists.apple.com/mailman/options/cocoa-dev/stephen.butler%40gmail.com > > This email sent to stephen.but...@gmail.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: string literals and performance
On May 24, 2014, at 21:08 , 2551 <2551p...@gmail.com> wrote: > Are there any performance implications that would suggest preferring one or > the other of these different styles? > > NSString *s = @"sing me a song"; > [myClass aMethod: s]; > > and > > [myClass aMethod: @"sing me a song”]; Basically — if not literally — no. > I have a lot of the first kind in my code, and I'm thinking of simplifying it > by turning them all into the second kind. There’s a good chance that the compiler already optimizes the first form into the second form. > A discussion on stackoverflow here: > > http://stackoverflow.com/questions/25746/whats-the-difference-between-a-string-constant-and-a-string-literal > > seems to suggest (if I've understood it correctly) that I'd be better off > sticking with the first style to avoid errors and to speed up comparisons. There is no difference in performance that you should consider *unless* you have documented evidence of certain string comparisons causing performance problem. Any other stance is unnecessary premature optimization (and you don’t know that it will make any kind of difference at all). The case discussed on SO where you use a global string variable is also unnecessary premature optimization, again unless you have some reason to believe you have a problem. If this really worries you, you can *try* to write a sample app where the source coding style leads to a measurable performance difference. If you can do it, post the code here, because I’m sure we’d all be flabbergasted to see it. ;) > However, since in my code they're all one-off 'throw away" strings that don't > get used elsewhere, that doesn't seem relevant. Is there any other reason why > I should stick with the first style rather than the second? No, the second style is better IMO: a. It’s less keystrokes to type. b. It’s clearer when you read the source code again later. OTOH, if you’ve got a method invocation that is very long, it could be be argued that splitting it into multiple lines (the first style) makes it easier to read. Since it’s almost entirely a stylistic matter, use the form that looks less ugly to you. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Understanding ARC
On May 24, 2014, at 5:04 PM, Jens Alfke wrote:
> On May 24, 2014, at 2:34 PM, Jamie Ojomoh wrote:
>
>> In the example, everything inside the autoreleasepool block will be
>> released as soon as the block ends, so it's necessary to declare the return
>> value outside the block.
>
> No, in general ARC understands that the return value needs to keep a
> reference, so it’s safe to put the return statement inside the autorelease
> block. In your specific example, returnString was allocated before you
> created your autorelease pool, so that pool won’t release it anyway. Also,
> you allocated returnString using an alloc/init sequence so it’s not in an
> autorelease pool at all.
This isn't strictly true; when you are returning objects by reference, doing so
inside the @autoreleasepool will cause a crash. For example:
#import
static BOOL DoSomethingElse(NSError *__autoreleasing *error) {
if (error) *error = [[NSError alloc] initWithDomain:@"Foo" code:-1
userInfo:nil];
return NO;
}
static BOOL DoSomething(NSError *__autoreleasing *error) {
@autoreleasepool {
return DoSomethingElse(error);
}
}
int main(int argc, const char * argv[]){
@autoreleasepool {
NSError *error = nil;
if (DoSomething(&error)) {
NSLog(@"Success");
} else {
NSLog(@"Error: %@", error); // crashes here
}
}
return 0;
}
Interestingly, this still happens even if you declare the NSError variable out
of the @autoreleasepool block:
#import
static BOOL DoSomethingElse(NSError *__autoreleasing *error) {
if (error) *error = [[NSError alloc] initWithDomain:@"Foo" code:-1
userInfo:nil];
return NO;
}
static BOOL DoSomething(NSError *__autoreleasing *error) {
NSError *theError = nil;
@autoreleasepool {
if (DoSomethingElse(&theError)) {
return YES;
} else {
if (error) *error = theError;
return NO;
}
}
}
int main(int argc, const char * argv[]){
@autoreleasepool {
NSError *error = nil;
if (DoSomething(&error)) {
NSLog(@"Success");
} else {
NSLog(@"Error: %@", error); // still crashes here
}
}
return 0;
}
The only thing that avoids the crash is returning outside of the
@autoreleasepool block:
#import
static BOOL DoSomethingElse(NSError *__autoreleasing *error) {
if (error) *error = [[NSError alloc] initWithDomain:@"Foo" code:-1
userInfo:nil];
return NO;
}
static BOOL DoSomething(NSError *__autoreleasing *error) {
BOOL success;
NSError *theError = nil;
@autoreleasepool {
success = DoSomethingElse(&theError);
}
if (success) {
return YES;
} else {
if (error) *error = theError;
return NO;
}
}
int main(int argc, const char * argv[]){
@autoreleasepool {
NSError *error = nil;
if (DoSomething(&error)) {
NSLog(@"Success");
} else {
NSLog(@"Error: %@", error); // now this actually works
}
}
return 0;
}
The thing that makes this really insidious is that you only get the crash when
an error occurs, so if you have an error case that only happens a tiny
percentage of the time, it can slip through your testing.
Charles
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
