The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
This deprecation is just apple cleaning up the headers for NSDateFormatter. init is already declared in NSObject which NSNumberFormatter inherits from. Redeclaring is not necessary, however in the implementation apple will override init as subclassess should provide implementations for the default initializer of the superclass.
ReplyDeleteLike falconcreek said here, Apple is just clearing the docs.
ReplyDeleteThat means that originally, - (id) init has been redeclared in the NSDateFormatter header file. That was unnecessary and somebody just removed it later. The documentation is probably generated automatically and didn't picked up that it was only the redecleration that was deprecated.
In short, use init as you wish with NSDateFormatter!
I would trust the header files over the documentation.
ReplyDeleteFor example, Formatter Behaviors and OS Versions seems to contradict itself:
By default, on Mac OS X v10.4 instances of NSDateFormatter have the same behavior as they did on Mac OS X versions 10.0 to 10.3. On Mac OS X v10.5 and later, NSDateFormatter defaults to the 10.4+ behavior.
If you initialize a formatter using initWithDateFormat:allowNaturalLanguage:, you are (for backwards compatibility reasons) creating an “old-style” date formatter. To use the new behavior, you initialize the formatter with init. If necessary, you can set the default class behavior using setDefaultFormatterBehavior:), you can set the behavior for an instance using setFormatterBehavior: message with the argument NSDateFormatterBehavior10_4.
It sounds like initWithDateFormat:allowNaturalLanguage: is actually the deprecated method?
That’s really strange. Maybe +[NSDateFormatter new] will do the job?
ReplyDeleteI use the init method in an multiple iOS4 apps and they are approved and in the store. I can think of no way to get it to work so it would seem like its just a typo on the docs.
ReplyDeleteThe example code in the class reference still uses the init method, so I'd say its safe to use it in your own code.
ReplyDeleteYou can proof yourself that NSDateFormatter has a different behaviour dependent on the initializer you choose and the SDK you are compiling with. The following is tested with SDK 10.5 and 10.6.
ReplyDeleteNSDateFormatter* df = [[NSDateFormatter alloc] initWithDateFormat:@"yyyyMMdd" allowNaturalLanguage:NO];
if ([df formatterBehavior] == NSDateFormatterBehavior10_0)
NSLog(@"NSDateFormatterBehavior10_0");
else if ([df formatterBehavior] == NSDateFormatterBehavior10_4)
NSLog(@"NSDateFormatterBehavior10_4");
This returns NSDateFormatterBehavior10_0.
Instead, when you use [[NSDateFormatter alloc] init]; the behaviour is NSDateFormatterBehavior10_4.