Re: Improve performance of data structure saved to disk
On 06 Aug 2015, at 15:36, Juanjo Conti wrote: > I've checked the number of entries and is only 350. They are regular > cookies for well known sites like google, new relic, twitter... That should not be a performance bottleneck. How often are you calling this (let's call it saveAllCookies for lack of a better term) on your entire cookie storage per whatever unit of time makes sense? Like, when a new cookie comes in, is there more than one call to saveAllCookies? > This is part of a CookieStorage class replacement, so I read/write the hole > storage each time a cookie is set or deleted. So, how large is the biggest cookie? What's the average size? If your cookies are large, it might be better to just individually serialize each cookie to its own file and then only write out ones that have actually changed. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://stacksmith.org ___ 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: How to implement NSSplitViewDelegate methods in an NSSplitViewController subclass
I think you're right on both counts. I will post this weekend about my solution to the other problem I posted about -- how to make collapse and uncollapse work both from a toggle button and by double-clicking or dragging the divider. It turns out that the frameworks use two different techniques for the two different scenarios, and that fact is not documented in the release notes, the reference document, or the header comments. In fact, the header comments for NSSplitViewItem (in NSSplitViewController.h) imply the opposite, falsely. -- Bill Cheeseman - wjcheese...@comcast.net > On Aug 7, 2015, at 4:40 PM, Fritz Anderson wrote: > > Speculation: This may be like the -window property of NSWindowController. > Accessing it is the recommended way to force the controller to instantiate > the window, even if you don’t care about the result. > > In this case, _you_ may not care what super’s NSSplitViewDelegate methods do, > but NSSplitViewController needs to hear about the events they represent. ___ 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: How to implement NSSplitViewDelegate methods in an NSSplitViewController subclass
> On 8 Aug 2015, at 14:06, Bill Cheeseman wrote: > > I think you're right on both counts. > > I will post this weekend about my solution to the other problem I posted > about -- how to make collapse and uncollapse work both from a toggle button > and by double-clicking or dragging the divider. It turns out that the > frameworks use two different techniques for the two different scenarios, and > that fact is not documented in the release notes, the reference document, or > the header comments. In fact, the header comments for NSSplitViewItem (in > NSSplitViewController.h) imply the opposite, falsely. One thing you might want to watch out for that caught me out: Although NSSplitViewController is documented to be the split view’s delegate, I found that — at least for controllers created in IB — that relationship isn’t actually hooked up by default. I overrode delegate methods and they weren’t being called. So I manually made the controller be the split view’s delegate, and all works. Mike. ___ 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: Auto-layout annoyance
On Aug 8, 2015, at 8:35 AM, SevenBits wrote: > > No, I’m afraid that didn’t work. Here are the constraints following your > suggestions: > > — Align Center X to Superview > — Trailing Space to Superview >= Default > — Leading Space to Superview >= Default > — Top Space to Superview Equals Default > — Bottom Space to (a button) Equals 14 > > This produces essentially the same behavior as before; though more of the > checkbox is shown because of the reduced trailing and leading space, the view > is still not shown and the parent view still does not adjust its width so > that the element fits on screen. I am not understanding the sentence above; “more of the checkbox is shown” and “the view is still not shown” appear to be at odds. What do you have the check box’s compression resistance priority set to? 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
Re: How to implement NSSplitViewDelegate methods in an NSSplitViewController subclass
> On Aug 8, 2015, at 9:31 AM, Mike Abdullah wrote: > > One thing you might want to watch out for that caught me out: > > Although NSSplitViewController is documented to be the split view’s delegate, > I found that — at least for controllers created in IB — that relationship > isn’t actually hooked up by default. I overrode delegate methods and they > weren’t being called. So I manually made the controller be the split view’s > delegate, and all works. I've seen your conclusion about the delegate problem online, but I have gone about it a little differently and get a better result. Namely, I create my subclass of the split view controller programmatically, and the delegate is in fact connected automatically. Specifically, I create a custom split view in my main window's nib file (no storyboards) so that I can set up its constraints easily, and I create two custom views for the two split view subviews in their own separate nib files. I subclass NSSplitViewController programmatically as a Swift 2.0 singleton class, and in its convenience initializer, in this order (the order is critical), (1) I replace the two empty subviews in the window's nib file's custom split view with my two custom views from their nib files (instantiating and initializing their separate view controller subclasses in the process), (2) I replace my subclassed split view controller's default split view with the custom split view in the main window's nib file, (3) I call addChildViewController() twice with the custom subviews' view controller subclasses, and (4) I replace my subclassed split view controller's default view with the custom split view in the main window's nib file. That fourth step might seem unnecessary, but it has the effect of marking my subclassed split view controller's view as loaded (it sets viewLoaded to true behind the scenes) and as a result viewDidLoad() is never called. It also prevents a crash if I access the split view controller's 'view' property instead of 'splitView' for any reason This sounds complicated, but it takes only 5 lines of very simple code. Then I implement several of the NSSplitViewDelegate delegate methods in my subclassed split view controller, and they are called exactly as documented -- even though I never set the split view's delegate programmatically or in the nib files. So I believe the documentation is correct, and the split view controller really is automatically made the split view's delegate (presumably in NSSplitViewItem). I think those who have done all this in a nib file or storyboard and discovered the delegate issue may have gotten something wrong in the preliminary setup -- which isn't surprising given how awful the documentation is. I would be happy to be corrected, but this part of my code is now working flawlessly and it is as simple and elegant as anything I've every written. I'm still struggling with the other part, collapsing and uncollapsing the bottom subview of the splitview both with a toggle button and with double-clicking or dragging the divider. I have that working, too, but there is one last cosmetic glitch I haven't yet resolved. -- Bill Cheeseman - wjcheese...@comcast.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
Nullability annotation "best practice"
Let's stipulate that _Nullable and _Nonnull are great to have because they can catch bugs and express API intent better than before, so we want them. The question is where to put them? _Nullable and _Nonnull make perfect sense to specify in the @interface. Since those annotations existing in the @interface will produce applicable warnings and errors in the counterpart @implementation,there's really no _need_ to respecify them in the @implementation of those same methods. It makes sense for private methods to have nullability annotations for all the same reasons public Now let's assume that private methods aren't specified in any @interface, even the anonymous one. In that case, those methods would naturally have no annotations on their parameters or return values unless they're specified within the @implementation. But specifying them on the private methods in the @implementation while *not* specifying them for the public methods in the @implementation is inconsistent and potentially confusing. So I see two choices here: 1) Always add nullability annotations, for all methods and properties in both the @interface and @implementation. (Private methods may or may not be declared within @interfaces — but these days I think it's generally not done?) 2) Only add nullability annotations in the @interface, and always declare private methods within an @interface. Is there a third choice I'm not thinking of? Thoughts? I'm curious how Apple is adopting these annotations themselves. -- Seth Willits ___ 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
