Navigation Design question
Hello all, I've run into an issue a few times and I'd like to see if someone has a good design suggestion to address my problem. Consider an iPad or iPhone application based on a UINavigationController - that displays a 'menu' button in the UINavigationBar. The navbar renders UIBarButtonItems ... which we set per the UIViewController level via the UINavigationItem which is available to us via the UIViewController. Now, I've got to render, for lack of a better term, a _global_ menu. I need the exact same button to simply stick to the upper left or right hand side of the nav bar. Consider that the button triggers the display of a UIPopoverController with a tableview which again, has _global_ style options. Specifically, and to keep the example simple, this menu has nothing to do with the child view controller. Maybe menu options include LOGOUT, or display SETTINGS or maybe there is an option to modally presents a report. How can I get this to show up - without forcing every single view controller to _know_ about this global menu, jam it into their own self.navigationItem.leftBarButtonItem property and be sure to register a handler from somewhere to do the right thing. What I think I _really_ want is a design wherein the view controller essentially _asks_ the navigation controller to either (a) add a very specific UIBarButtonItem to the navigation bar (which would allow the navigation controller to add the button to an array if a global button already existed) ... or (b) add a selection option - which the navigation bar could decide how to handle (create a new button, or insert into an existing menu, etc). What makes rolling my own wrappers around this difficult is that those things are set via the UINavigationItem - which is very very specific to the view controller itself - it isn't directly available to the navigation controller per se. I'm leaning towards adding something like: - (void)addBarButtonItem:(UIBarButtonItem *)barButtonItem toNavigationItem:(UINavigationItem *)navigationItem; - (void)addMenuOption:(idMenuOption)option toNavigationItem:(UINavigationItem *)navigationItem; to either a category or subclass of the UINavigationController I am using to handle the case where I want to _add_ my requirements to whatever the UINavigationController is already displaying ... the problem is, if a view controller has _nothing_ to add to the nav bar, the global menu addition wouldn't get triggered I wonder if I need to shift my focus to the UINavigationBar itself -- and intercept calls trying to create buttons ... but that be new territory for me as I've always just depended on the meta-informational style of using the view controller's UINavigationItem. Any thoughts on this? Has anyone discovered a better way to do this without cluttering up every child view controller's SRP with the necessity to set buttons for someone else while retaining ultimate flexibility to set their own -- while still not having a way to 'insert' an option into an existing partially _global_ menu that is floating from vc to vc. I essentially don't want view controllers setting these items directly - I want them to _add_ items - not _set_ them. And I'm not sure how to do this within the design paradigm of the view controller's navigation item instance - since that just puts me at one more level of direction (someone else reads that object and then builds out the UINavigationBar accordingly). Ok - getting wordy and repetitive. Hope I've said enough to be clear what I'm trying to do. Thanks, -Luther ___ 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: Navigation Design question
You can add a category on UIViewController, do some detection and swizzle -[UIViewController viewWillAppear:] method. On Apr 14, 2014, at 5:55, Luther Baker lutherba...@gmail.com wrote: Hello all, I've run into an issue a few times and I'd like to see if someone has a good design suggestion to address my problem. Consider an iPad or iPhone application based on a UINavigationController - that displays a 'menu' button in the UINavigationBar. The navbar renders UIBarButtonItems ... which we set per the UIViewController level via the UINavigationItem which is available to us via the UIViewController. Now, I've got to render, for lack of a better term, a _global_ menu. I need the exact same button to simply stick to the upper left or right hand side of the nav bar. Consider that the button triggers the display of a UIPopoverController with a tableview which again, has _global_ style options. Specifically, and to keep the example simple, this menu has nothing to do with the child view controller. Maybe menu options include LOGOUT, or display SETTINGS or maybe there is an option to modally presents a report. How can I get this to show up - without forcing every single view controller to _know_ about this global menu, jam it into their own self.navigationItem.leftBarButtonItem property and be sure to register a handler from somewhere to do the right thing. What I think I _really_ want is a design wherein the view controller essentially _asks_ the navigation controller to either (a) add a very specific UIBarButtonItem to the navigation bar (which would allow the navigation controller to add the button to an array if a global button already existed) ... or (b) add a selection option - which the navigation bar could decide how to handle (create a new button, or insert into an existing menu, etc). What makes rolling my own wrappers around this difficult is that those things are set via the UINavigationItem - which is very very specific to the view controller itself - it isn't directly available to the navigation controller per se. I'm leaning towards adding something like: - (void)addBarButtonItem:(UIBarButtonItem *)barButtonItem toNavigationItem:(UINavigationItem *)navigationItem; - (void)addMenuOption:(idMenuOption)option toNavigationItem:(UINavigationItem *)navigationItem; to either a category or subclass of the UINavigationController I am using to handle the case where I want to _add_ my requirements to whatever the UINavigationController is already displaying ... the problem is, if a view controller has _nothing_ to add to the nav bar, the global menu addition wouldn't get triggered I wonder if I need to shift my focus to the UINavigationBar itself -- and intercept calls trying to create buttons ... but that be new territory for me as I've always just depended on the meta-informational style of using the view controller's UINavigationItem. Any thoughts on this? Has anyone discovered a better way to do this without cluttering up every child view controller's SRP with the necessity to set buttons for someone else while retaining ultimate flexibility to set their own -- while still not having a way to 'insert' an option into an existing partially _global_ menu that is floating from vc to vc. I essentially don't want view controllers setting these items directly - I want them to _add_ items - not _set_ them. And I'm not sure how to do this within the design paradigm of the view controller's navigation item instance - since that just puts me at one more level of direction (someone else reads that object and then builds out the UINavigationBar accordingly). Ok - getting wordy and repetitive. Hope I've said enough to be clear what I'm trying to do. Thanks, -Luther ___ 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/xcvista%40me.com This email sent to xcvi...@me.com 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: Navigation Design question
Why not just make a common UIViewController subclass that manages the global menu button, and then subclass that class for each of the controllers that live on your navigation stack? If it contains the ivar for the UINavigationItem (marked @protected) instead of having that ivar in each of the custom controllers, then it has access to it to manage the global menu button, and the subclasses can also perform whatever custom bits are required. It also means that each of the sub-subclasses don’t need to be calling -addBarButtonItem:… or know how the global menu works. The controller class that knows about the global menu button then implements -addMenuOption: (not -addMenuOption:navigationItem:, since it already knows the navigation item) and the sub-subclasses call it to add an option. On Apr 13, 2014, at 2:55 PM, Luther Baker lutherba...@gmail.com wrote: Hello all, I've run into an issue a few times and I'd like to see if someone has a good design suggestion to address my problem. Consider an iPad or iPhone application based on a UINavigationController - that displays a 'menu' button in the UINavigationBar. The navbar renders UIBarButtonItems ... which we set per the UIViewController level via the UINavigationItem which is available to us via the UIViewController. Now, I've got to render, for lack of a better term, a _global_ menu. I need the exact same button to simply stick to the upper left or right hand side of the nav bar. Consider that the button triggers the display of a UIPopoverController with a tableview which again, has _global_ style options. Specifically, and to keep the example simple, this menu has nothing to do with the child view controller. Maybe menu options include LOGOUT, or display SETTINGS or maybe there is an option to modally presents a report. How can I get this to show up - without forcing every single view controller to _know_ about this global menu, jam it into their own self.navigationItem.leftBarButtonItem property and be sure to register a handler from somewhere to do the right thing. What I think I _really_ want is a design wherein the view controller essentially _asks_ the navigation controller to either (a) add a very specific UIBarButtonItem to the navigation bar (which would allow the navigation controller to add the button to an array if a global button already existed) ... or (b) add a selection option - which the navigation bar could decide how to handle (create a new button, or insert into an existing menu, etc). What makes rolling my own wrappers around this difficult is that those things are set via the UINavigationItem - which is very very specific to the view controller itself - it isn't directly available to the navigation controller per se. I'm leaning towards adding something like: - (void)addBarButtonItem:(UIBarButtonItem *)barButtonItem toNavigationItem:(UINavigationItem *)navigationItem; - (void)addMenuOption:(idMenuOption)option toNavigationItem:(UINavigationItem *)navigationItem; to either a category or subclass of the UINavigationController I am using to handle the case where I want to _add_ my requirements to whatever the UINavigationController is already displaying ... the problem is, if a view controller has _nothing_ to add to the nav bar, the global menu addition wouldn't get triggered I wonder if I need to shift my focus to the UINavigationBar itself -- and intercept calls trying to create buttons ... but that be new territory for me as I've always just depended on the meta-informational style of using the view controller's UINavigationItem. Any thoughts on this? Has anyone discovered a better way to do this without cluttering up every child view controller's SRP with the necessity to set buttons for someone else while retaining ultimate flexibility to set their own -- while still not having a way to 'insert' an option into an existing partially _global_ menu that is floating from vc to vc. I essentially don't want view controllers setting these items directly - I want them to _add_ items - not _set_ them. And I'm not sure how to do this within the design paradigm of the view controller's navigation item instance - since that just puts me at one more level of direction (someone else reads that object and then builds out the UINavigationBar accordingly). Ok - getting wordy and repetitive. Hope I've said enough to be clear what I'm trying to do. Thanks, -Luther ___ 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/punster%40mac.com This email sent to puns...@mac.com ___ Cocoa-dev mailing list
Design Question
I want to display a window as a modal dialog. Should I use just a Window Controller or also define another class that handles the window contents. -koko___ 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
Re: Design Question
That is what I thought but just wanted too verify … thanks. -koko On Nov 26, 2011, at 12:28 PM, Dave Fernandes wrote: You can just subclass NSWindowController and make that subclass the File's Owner. Sent from my iPhone On 2011-11-26, at 2:14 PM, koko k...@highrolls.net wrote: I want to display a window as a modal dialog. Should I use just a Window Controller or also define another class that handles the window contents. -koko___ 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/dave.fernandes%40utoronto.ca This email sent to dave.fernan...@utoronto.ca ___ 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
Document-based app: design question
Hi, I'm using the following piece of code in several places to get a pointer to the active windowController in my document-based application: NSDocument *currentDocument = [[NSDocumentController sharedDocumentController] currentDocument]; if (!currentDocument) return; NSWindowController *windowController = [[currentDocument windowControllers] objectAtIndex:0]; if (![windowController isMemberOfClass:[DSSketchLibraryWindowController class]]) return; Obviously, I'm looking for a way to refactor this duplicate code. Since this code is used in several different classes, I need to put it someplace where I can easily reference it. AppDelegate comes to mind. So, I'm wondering if putting this code in a public method in the application delegate would be the correct cocoa way of doing things? Thanks for any advice. -- Luc Van Bogaert. ___ 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
Re: Document-based app: design question
One way of dealing with this is to make the method part of an informal protocol and check before calling it. Details are here: http://cocoadevcentral.com/articles/75.php -- David Kennedy (http://www.zenopolis.com) On 21 Oct 2011, at 08:39, Luc Van Bogaert wrote: Hi, I'm using the following piece of code in several places to get a pointer to the active windowController in my document-based application: NSDocument *currentDocument = [[NSDocumentController sharedDocumentController] currentDocument]; if (!currentDocument) return; NSWindowController *windowController = [[currentDocument windowControllers] objectAtIndex:0]; if (![windowController isMemberOfClass:[DSSketchLibraryWindowController class]]) return; Obviously, I'm looking for a way to refactor this duplicate code. Since this code is used in several different classes, I need to put it someplace where I can easily reference it. AppDelegate comes to mind. So, I'm wondering if putting this code in a public method in the application delegate would be the correct cocoa way of doing things? Thanks for any advice. -- Luc Van Bogaert. ___ 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/citizen%40zenopolis.com This email sent to citi...@zenopolis.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
Re: iOS UI Design Question / Opinions wanted
On Thu, Jul 14, 2011 at 1:25 AM, Roland King r...@rols.org wrote: Custom button with your own graphic tick/cross is probably what I'd use for this. That's easy to do and fits pretty well with the ios look and feel. Either have two buttons and use them as radio buttons (unselect one when you hit the other) or if perhaps try one button which switches states each time you hit it. If that had a graphic with a large tick and small cross for the yes state and the opposite for the no state it would be quite obvious that you need to hit it to toggle. Hm.. Yeah, that sounds like a good idea, that seems like it would work. Thanks! ___ 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
Re: iOS UI Design Question / Opinions wanted
On 14 Jul 2011, at 06:05, John Tsombakos wrote: Hi, Just getting more into iOS development, and am deciding on what to do for an app. One app is a competition scoring application, where the judges would use the app to calculate and score a game. The scores would are derived from a series of challenges, each worth a set number of points. Each challenge score is determined by a Yes/No completion - Did XYZ happen? Did The other thing happen? etc. I was trying to figure out how to design the UI and while for a web version that we already have that uses radio buttons for each question, I'm not sure what would be best for an iOS app. I looked at the UISwitch, but it shows On/Off and that's not quite right. A segmented control could possibly work, with one for Yes and one for No. I thought a checkbox to signify Yes - but it doesn't look like iOS has checkboxes (how did I never notice that!). I want to make it simple, so popping up a separate alert/window would incur an extra step. So I'm soliciting opinions / suggestions. Along with various other people, I have a custom UISwitch that does exactly what you require, it's available here http://whataboutapp.co.uk/ Tom Davie___ 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
Re: iOS UI Design Question / Opinions wanted
On Thu, Jul 14, 2011 at 8:14 AM, Thomas Davie tom.da...@gmail.com wrote: Along with various other people, I have a custom UISwitch that does exactly what you require, it's available here http://whataboutapp.co.uk/ Tom Davie That looks exactly what I would want! Thanks! ___ 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
Re: iOS UI Design Question / Opinions wanted
On Thu, Jul 14, 2011 at 9:26 AM, John Tsombakos joh...@charter.net wrote: On Thu, Jul 14, 2011 at 8:14 AM, Thomas Davie tom.da...@gmail.com wrote: Along with various other people, I have a custom UISwitch that does exactly what you require, it's available here http://whataboutapp.co.uk/ Tom Davie That looks exactly what I would want! Thanks! Hm. Checking it out, looks promising. However, is there a way to put the control into a view in Interface Builder? Or do you have to do it in code (alloc/initWithFrame)? There isn't any docs included with the library. Thanks! ___ 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
iOS UI Design Question / Opinions wanted
Hi, Just getting more into iOS development, and am deciding on what to do for an app. One app is a competition scoring application, where the judges would use the app to calculate and score a game. The scores would are derived from a series of challenges, each worth a set number of points. Each challenge score is determined by a Yes/No completion - Did XYZ happen? Did The other thing happen? etc. I was trying to figure out how to design the UI and while for a web version that we already have that uses radio buttons for each question, I'm not sure what would be best for an iOS app. I looked at the UISwitch, but it shows On/Off and that's not quite right. A segmented control could possibly work, with one for Yes and one for No. I thought a checkbox to signify Yes - but it doesn't look like iOS has checkboxes (how did I never notice that!). I want to make it simple, so popping up a separate alert/window would incur an extra step. So I'm soliciting opinions / suggestions. Thanks, John T. ___ 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
Re: iOS UI Design Question / Opinions wanted
Custom button with your own graphic tick/cross is probably what I'd use for this. That's easy to do and fits pretty well with the ios look and feel. Either have two buttons and use them as radio buttons (unselect one when you hit the other) or if perhaps try one button which switches states each time you hit it. If that had a graphic with a large tick and small cross for the yes state and the opposite for the no state it would be quite obvious that you need to hit it to toggle. On Jul 14, 2011, at 13:05, John Tsombakos joh...@charter.net wrote: Hi, Just getting more into iOS development, and am deciding on what to do for an app. One app is a competition scoring application, where the judges would use the app to calculate and score a game. The scores would are derived from a series of challenges, each worth a set number of points. Each challenge score is determined by a Yes/No completion - Did XYZ happen? Did The other thing happen? etc. I was trying to figure out how to design the UI and while for a web version that we already have that uses radio buttons for each question, I'm not sure what would be best for an iOS app. I looked at the UISwitch, but it shows On/Off and that's not quite right. A segmented control could possibly work, with one for Yes and one for No. I thought a checkbox to signify Yes - but it doesn't look like iOS has checkboxes (how did I never notice that!). I want to make it simple, so popping up a separate alert/window would incur an extra step. So I'm soliciting opinions / suggestions. Thanks, John T. ___ 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/rols%40rols.org This email sent to r...@rols.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: design question
thank you very much for your answers. 2011/3/23 Graham Cox graham@bigpond.com On 23/03/2011, at 11:58 AM, Quincey Morris wrote: 1b. The property is a to-many relationship. If #1a, then the return value should be unchangeable, in the sense that it should never change after being returned (regardless of whether the returned object is of a mutable class or not). That means, if an existing mutable array is the desired return value, which the owning class might mutate later, a copy *must* be returned instead. If #1b, then the return value should be assumed to be changeable, in the sense that it could change any time after being returned. (Again, the return value's class's mutability is irrelevant.) *Semantically, what's being returned is a proxy for the relationship*, not an array. In this case, the return type merely indicates whether the caller can mutate the relationship via the proxy or not. In practice, it works in reverse. If the method returns something unchangeable, the property is regarded as an attribute. If it returns something changeable, the property is regarded as a to-many relationship. This is consistent with Core Data properties, and keeping the distinction clear keeps the API design honest and helps write correct code -- it makes it easy to decide whether to return a copy of the underlying array or not. Your discussion about how long and why has different answers depending on which of the two kinds of properties is involved. The pitfall here is that if the property is intended to be a snapshot of the state of a relationship (an attribute, as opposed to the actual relationship), returning the underlying mutable array without copying is a bug, even if the return type is NSArray. Right, and I agree. You've expressed it better than I did, sometimes it's hard to convey in writing something that you have only understood at some intuitive level. So this helps clarify something I hadn't made entirely clear in my own mind. The situation is #1b. And you know this, because you have more information than just a return type - you have the name of the method, -children. This pretty much tells you that you're dealing with a to-many relationship. If it doesn't, you've named it badly. Thus, a client can and should expect it to change, and so, if it actually wants a snapshot, it should perform the copy, but if not, it shouldn't cache it. Either way, in my view the onus is on the client as to whether to perform the copy - the vending object doesn't know what the client is going to use it for, so whether to copy it or not is not something it can know, so it should do the simplest thing (an instance of Occam's Razor?) which is, not copy. In practice, you rarely run into problems with this approach. I know everyone will have their favourite counter-examples, but that's why I say 'rarely', not 'never'. --Graham -- best regards Ariel ___ 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
Re: design question
On Mar 22, 2011, at 16:53, Graham Cox wrote: That's because a) NSMutableArray IS a NSArray, and b) your method has told its clients it is returning an NSArray, so the client has no right to go any further than the methods of NSArray with that object, that is, it cannot make use of knowledge it doesn't have to treat it as mutable. If you want the client to know that the array really is mutable, your return type should say so. I agree with this part. The client would have to examine the class at runtime to find out it was mutable, and that would be a bug. The only issue is whether having returned the array, its contents could mutate while someone else is retaining it. But if the client is holding onto it that long (in a synchronous situation) its contents won't reflect the reality of the content of the object it got it from in any case. Alternatively, once the tree is built from the XML document, why would the structure change? If you're writing an editor, the structure will change, but in that case you probably won't have a case where a stale copy of 'children' is cached anywhere. In all the typical cases, the copy is likely redundant. If a client knows that it will be holding on to the array for a long time, and that it got it from an object whose contents are probably dynamic (according to this very common pattern) then it can make a copy itself if it needs to. It is in a better position than the vending object to know whether the copy is needed or not (which is why most copying that is done is implemented by an object setter, not in a getter). On the other hand whether to copy or not is really a (usually minor) performance issue rather than anything more fundamental, so worrying about it now is unlikely to be worthwhile. However I think that paranoia leading to copying everything everywhere indicates a basic lack of understanding about the design you're implementing. By habit and reflex, not copying is the norm, and copying should only be done when it is understood that it is truly necessary. Doing it just in case is pointless. I disagree with you on this part. It's slightly more complex than that. There are 2 basic *semantic* possibilities: 1. This method is the implementation of a property (whether or not it's an @property isn't important). 2. This method is just a method. If #2, there's nothing to be discussed. The behavior of the return value is a matter for the API contract for that method, and there's no general rule. Often, though, #2 isn't the intended meaning for a method that takes no parameters and returns a value. If #1, then there's a second pair of more interesting possibilities: 1a. The property is an attribute. 1b. The property is a to-many relationship. If #1a, then the return value should be unchangeable, in the sense that it should never change after being returned (regardless of whether the returned object is of a mutable class or not). That means, if an existing mutable array is the desired return value, which the owning class might mutate later, a copy *must* be returned instead. If #1b, then the return value should be assumed to be changeable, in the sense that it could change any time after being returned. (Again, the return value's class's mutability is irrelevant.) *Semantically, what's being returned is a proxy for the relationship*, not an array. In this case, the return type merely indicates whether the caller can mutate the relationship via the proxy or not. In practice, it works in reverse. If the method returns something unchangeable, the property is regarded as an attribute. If it returns something changeable, the property is regarded as a to-many relationship. This is consistent with Core Data properties, and keeping the distinction clear keeps the API design honest and helps write correct code -- it makes it easy to decide whether to return a copy of the underlying array or not. Your discussion about how long and why has different answers depending on which of the two kinds of properties is involved. The pitfall here is that if the property is intended to be a snapshot of the state of a relationship (an attribute, as opposed to the actual relationship), returning the underlying mutable array without copying is a bug, even if the return type is NSArray. ___ 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
Re: design question
On 23/03/2011, at 11:58 AM, Quincey Morris wrote: 1b. The property is a to-many relationship. If #1a, then the return value should be unchangeable, in the sense that it should never change after being returned (regardless of whether the returned object is of a mutable class or not). That means, if an existing mutable array is the desired return value, which the owning class might mutate later, a copy *must* be returned instead. If #1b, then the return value should be assumed to be changeable, in the sense that it could change any time after being returned. (Again, the return value's class's mutability is irrelevant.) *Semantically, what's being returned is a proxy for the relationship*, not an array. In this case, the return type merely indicates whether the caller can mutate the relationship via the proxy or not. In practice, it works in reverse. If the method returns something unchangeable, the property is regarded as an attribute. If it returns something changeable, the property is regarded as a to-many relationship. This is consistent with Core Data properties, and keeping the distinction clear keeps the API design honest and helps write correct code -- it makes it easy to decide whether to return a copy of the underlying array or not. Your discussion about how long and why has different answers depending on which of the two kinds of properties is involved. The pitfall here is that if the property is intended to be a snapshot of the state of a relationship (an attribute, as opposed to the actual relationship), returning the underlying mutable array without copying is a bug, even if the return type is NSArray. Right, and I agree. You've expressed it better than I did, sometimes it's hard to convey in writing something that you have only understood at some intuitive level. So this helps clarify something I hadn't made entirely clear in my own mind. The situation is #1b. And you know this, because you have more information than just a return type - you have the name of the method, -children. This pretty much tells you that you're dealing with a to-many relationship. If it doesn't, you've named it badly. Thus, a client can and should expect it to change, and so, if it actually wants a snapshot, it should perform the copy, but if not, it shouldn't cache it. Either way, in my view the onus is on the client as to whether to perform the copy - the vending object doesn't know what the client is going to use it for, so whether to copy it or not is not something it can know, so it should do the simplest thing (an instance of Occam's Razor?) which is, not copy. In practice, you rarely run into problems with this approach. I know everyone will have their favourite counter-examples, but that's why I say 'rarely', not 'never'. --Graham ___ 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
Re: Core Data design question: receiving KVO notifications of partially mutated objects
On 11/2/09 12:58 PM, Ben Trumbull said: This doesn't really have anything to do with Core Data. However, for NSManagedObject, Core Data already provides the change coalescing and NSNotifications for you. You can respond within NSManagedObjectContextObjectsDidChangeNotification instead. So I read the various archive posts about that notification and played with it a little. I can see it being handy, especially for added and removed objects. The big shortcoming, in my situation anyway, is that it does not seem to provide me with the keys that changed (in the NSUpdatedObjectsKey case). Unless I'm missing something? Thanks, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
re: Core Data design question: receiving KVO notifications of partially mutated objects
What is considered best practice when it comes to mutating many properties of a managed object, specifically with regard to KVO observers getting notified before all mutations are finished? This is a problem intrinsic to the design of KVO. KVO is all about fine grained per property notifications. It's very well suited to that. However, it's common for complex objects to be in an intermediate state during a KVO notification. There's no better notion of cross-property coherence than refactoring into a different property object that encapsulates everything. Let's say I have an Rectangle object. It has properties: colour, width, height. Imagine some controller observing all these properties, perhaps to trigger a redraw. If I do: [rect setColour:...]; [rect setWidth:...]; [rect setHeight:...]; In this example, the best KVO can do is work with a colored rectangle object that in turn is the 1 property you work with here. So, this would be an example of a granularity of notification that works better with NSNotificationCenter This is short and readable. But observers will be notified after each setter. yup This could be a problem if intermediate states are not self- consistent and could also lead to unnecessary redrawing. And many other performance issues if observers recalculate things too aggressively. In the general case, I might not even know who is observing. Well, that's the point of the notification pattern. I guess it's safer to create a setColour:width:height: method in my NSManagedObject subclass that does: [self willAccessValueForKey:@colour]; [self willAccessValueForKey:@width]; [self setPrimitiveColour:...]; [self setPrimitiveWidth:...]; [self didAccessValueForKey:@width]; [self didAccessValueForKey:@colour]; Is this what I should be doing? Generally, no. (setting aside, the calls should be to willChangeValueForKey:, btw) If your issue is that drawing or recalculation is occurring too frequently after KVO changes, you can consider coalescing and deferring the observers' actions instead of performing them synchronously. This can be valuable even for less complex KVO issues. You could also refactor the 3 properties into 1 object. Or use an NSNotification instead of KVO to adjust the granularity of notifications to better suit your drawing code. This doesn't really have anything to do with Core Data. However, for NSManagedObject, Core Data already provides the change coalescing and NSNotifications for you. You can respond within NSManagedObjectContextObjectsDidChangeNotification instead. - Ben ___ 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
Re: Core Data design question: receiving KVO notifications of partially mutated objects
Graham, Thanks for the detailed reply! I'd say you're going down the wrong path there. Agreed, hence my post. :) Set each property individually. Yes, it will trigger a notification for each one - doesn't or shouldn't matter, and unless you can show it causes a performance problem, shouldn't be a cause for worry on that score. It won't cause multiple redrawing, because even if each one posted a -setNeedsDisplayInRect:, the actual drawing will not get processed until the next update cycle and invalidating the same area three times still only results in one redraw, by which time all the properties will be set. Drawing performance is not an issue here (unless you are bypassing the update mechanism and forcing the drawing on a notification, but that's a different wrong, so you're not doing that, are you?). My 'Rectangle' object with colour, width, and height attributes was an example of course. I should probably have clarified that or just not have used drawing as an example. You are right about the whole redraw mechanism of course, and my drawing is in fact fine, and I'm not doing anything mischievous there. The question of whether the separate notifications lead to an invalid intermediate state is a more reasonable problem to consider, but it normally shouldn't matter either. Normally KVO will be used to update your UI and/or maintain undo. You mention Core Data so that will handle undo for you but even if you were doing that yourself it shouldn't matter. Undo will record each property change and group them, so you end up with one undo that undoes all three property changes. Any UI that represents each property will also update all at once (or appear to) because the drawing update cycle won't actually show changes until the update runs and flushes the changes to the backing store. In general, I've found things do indeed work that way, and they work well. As a general rule you can and should treat each property in isolation. Even if some command sets several at once, you should find that it all works correctly unless you've gone out of your way to depend on some property state always being paired with some other property state, in which case you should probably make that state pair a separate property. I think as a general rule the approach you're proposing is unnecessary and untidy. I'm starting to think perhaps the root of my problem is that I am using KVO in my controller layer to do things that should be done in my model layer. Sometimes the creation of one ManagedObject, say type 'Foo', requires that: - several other ManagedObjects be created and related. - several existing ManagedObjects be found and related. Where is the right place to do such a thing? Currently, I often do it by KVO observing, in my NSDocument, the creation of new Foos. When I detect new ones, I'll perform some fetches, create new objects, relate them appropriately, etc. (In the past, I tried doing such things inside Foo's awakeFromInsert but I discovered that performing a fetch from that function leads to various problems.) Thanks, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: Core Data design question: receiving KVO notifications of partially mutated objects
On 11/2/09 12:58 PM, Ben Trumbull said: What is considered best practice when it comes to mutating many properties of a managed object, specifically with regard to KVO observers getting notified before all mutations are finished? This is a problem intrinsic to the design of KVO. KVO is all about fine grained per property notifications. It's very well suited to that. However, it's common for complex objects to be in an intermediate state during a KVO notification. There's no better notion of cross-property coherence than refactoring into a different property object that encapsulates everything. Let's say I have an Rectangle object. It has properties: colour, width, height. Imagine some controller observing all these properties, perhaps to trigger a redraw. If I do: [rect setColour:...]; [rect setWidth:...]; [rect setHeight:...]; In this example, the best KVO can do is work with a colored rectangle object that in turn is the 1 property you work with here. So, this would be an example of a granularity of notification that works better with NSNotificationCenter This is short and readable. But observers will be notified after each setter. yup This could be a problem if intermediate states are not self- consistent and could also lead to unnecessary redrawing. And many other performance issues if observers recalculate things too aggressively. In the general case, I might not even know who is observing. Well, that's the point of the notification pattern. I guess it's safer to create a setColour:width:height: method in my NSManagedObject subclass that does: [self willAccessValueForKey:@colour]; [self willAccessValueForKey:@width]; [self setPrimitiveColour:...]; [self setPrimitiveWidth:...]; [self didAccessValueForKey:@width]; [self didAccessValueForKey:@colour]; Is this what I should be doing? Generally, no. (setting aside, the calls should be to willChangeValueForKey:, btw) Ben, Thanks for all the above comments, they have each connected a few dots in my mind. If your issue is that drawing or recalculation is occurring too frequently after KVO changes, you can consider coalescing and deferring the observers' actions instead of performing them synchronously. This can be valuable even for less complex KVO issues. You could also refactor the 3 properties into 1 object. Alas, that would require 1) persistent store migration (painful on 10.5) and 2) I find it very handy to be able to bind 'colour' to a colourwell and 'width' and 'height' to text fields. Perhaps I have bent my model too much in favour of my UI also. :) But anyway, this 'Rectangle' object was just an example. My real app is a bit harder to explain. Or use an NSNotification instead of KVO to adjust the granularity of notifications to better suit your drawing code. This doesn't really have anything to do with Core Data. However, for NSManagedObject, Core Data already provides the change coalescing and NSNotifications for you. You can respond within NSManagedObjectContextObjectsDidChangeNotification instead. Perhaps NSManagedObjectContextObjectsDidChangeNotification is the thing I have overlooked! I currently use it almost nowhere but have tonnes and tonnes of KVO observing going on. I'll have to RTFM on NSManagedObjectC ontextObjectsDidChangeNotification. Questions that pop to mind though: is it safe for me to fetch? to create/delete/mutate ManagedObjects? Ultimately, my recent problem with 'dangling reference to an invalid object' made me realise I probably have some design problems, which I can't quite put my finger on. I'm pretty sure I'm misusing/abusing KVO however. Thanks, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: Core Data design question: receiving KVO notifications of partially mutated objects
If your issue is that drawing or recalculation is occurring too frequently after KVO changes, you can consider coalescing and deferring the observers' actions instead of performing them synchronously. This can be valuable even for less complex KVO issues. You could also refactor the 3 properties into 1 object. Alas, that would require 1) persistent store migration (painful on 10.5) and 2) I find it very handy to be able to bind 'colour' to a colourwell and 'width' and 'height' to text fields. Perhaps I have bent my model too much in favour of my UI also. :) But anyway, this 'Rectangle' object was just an example. My real app is a bit harder to explain. Or use an NSNotification instead of KVO to adjust the granularity of notifications to better suit your drawing code. This doesn't really have anything to do with Core Data. However, for NSManagedObject, Core Data already provides the change coalescing and NSNotifications for you. You can respond within NSManagedObjectContextObjectsDidChangeNotification instead. Perhaps NSManagedObjectContextObjectsDidChangeNotification is the thing I have overlooked! I currently use it almost nowhere but have tonnes and tonnes of KVO observing going on. I'll have to RTFM on NSManagedObjectC ontextObjectsDidChangeNotification. Questions that pop to mind though: is it safe for me to fetch? to create/delete/mutate ManagedObjects? I'd recommend performing a selector after delay 0. You can inspect the objects and decide what you want to do with them. The notification is posted from within the change tracking code, so making changes could possibly result in them getting caught in between 1 user event and the next. - Ben ___ 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
Core Data design question: receiving KVO notifications of partially mutated objects
Hi all, What is considered best practice when it comes to mutating many properties of a managed object, specifically with regard to KVO observers getting notified before all mutations are finished? Let's say I have an Rectangle object. It has properties: colour, width, height. Imagine some controller observing all these properties, perhaps to trigger a redraw. If I do: [rect setColour:...]; [rect setWidth:...]; [rect setHeight:...]; This is short and readable. But observers will be notified after each setter. This could be a problem if intermediate states are not self- consistent and could also lead to unnecessary redrawing. In the general case, I might not even know who is observing. I guess it's safer to create a setColour:width:height: method in my NSManagedObject subclass that does: [self willAccessValueForKey:@colour]; [self willAccessValueForKey:@width]; [self setPrimitiveColour:...]; [self setPrimitiveWidth:...]; [self didAccessValueForKey:@width]; [self didAccessValueForKey:@colour]; Is this what I should be doing? I can see it getting ugly with more than 3 or so properties... Thanks, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: Core Data design question: receiving KVO notifications of partially mutated objects
On 31/10/2009, at 9:01 AM, Sean McBride wrote: Hi all, What is considered best practice when it comes to mutating many properties of a managed object, specifically with regard to KVO observers getting notified before all mutations are finished? In situations like these I personally tend to avoid KVO. It's too noisy and in some cases incurs too much of a performance overhead. But, I have a solution which I describe below. Let's say I have an Rectangle object. It has properties: colour, width, height. Imagine some controller observing all these properties, perhaps to trigger a redraw. If I do: [rect setColour:...]; [rect setWidth:...]; [rect setHeight:...]; This is short and readable. But observers will be notified after each setter. This could be a problem if intermediate states are not self- consistent and could also lead to unnecessary redrawing. In the general case, I might not even know who is observing. I guess it's safer to create a setColour:width:height: method in my NSManagedObject subclass that does: [self willAccessValueForKey:@colour]; [self willAccessValueForKey:@width]; [self setPrimitiveColour:...]; [self setPrimitiveWidth:...]; [self didAccessValueForKey:@width]; [self didAccessValueForKey:@colour]; Is this what I should be doing? I can see it getting ugly with more than 3 or so properties... Perhaps make a property that represents the state of the value these dependent properties contribute to? For example, is it possible to have a requires redraw property of the Rectangle? You could simply change the value of that property (in the overridden setColor:, setWidth:, setLength: methods *sigh*) to indicate the Rectangle object requires a redraw? Then, when a third party wants the value of the dependent property, you can recalculate it. In the given example, the rectangle will only re-draw when it's needed. Just a few ideas, not sure if they're of any help. They're not coming from a Core Data perspective either, just a general one - but I wouldn't expect it to be much different? Kiel ___ 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
Re: Core Data design question: receiving KVO notifications of partially mutated objects
Hi Sean, I'd say you're going down the wrong path there. Set each property individually. Yes, it will trigger a notification for each one - doesn't or shouldn't matter, and unless you can show it causes a performance problem, shouldn't be a cause for worry on that score. It won't cause multiple redrawing, because even if each one posted a -setNeedsDisplayInRect:, the actual drawing will not get processed until the next update cycle and invalidating the same area three times still only results in one redraw, by which time all the properties will be set. Drawing performance is not an issue here (unless you are bypassing the update mechanism and forcing the drawing on a notification, but that's a different wrong, so you're not doing that, are you?). The question of whether the separate notifications lead to an invalid intermediate state is a more reasonable problem to consider, but it normally shouldn't matter either. Normally KVO will be used to update your UI and/or maintain undo. You mention Core Data so that will handle undo for you but even if you were doing that yourself it shouldn't matter. Undo will record each property change and group them, so you end up with one undo that undoes all three property changes. Any UI that represents each property will also update all at once (or appear to) because the drawing update cycle won't actually show changes until the update runs and flushes the changes to the backing store. As a general rule you can and should treat each property in isolation. Even if some command sets several at once, you should find that it all works correctly unless you've gone out of your way to depend on some property state always being paired with some other property state, in which case you should probably make that state pair a separate property. I think as a general rule the approach you're proposing is unnecessary and untidy. --Graham On 31/10/2009, at 9:01 AM, Sean McBride wrote: Let's say I have an Rectangle object. It has properties: colour, width, height. Imagine some controller observing all these properties, perhaps to trigger a redraw. If I do: [rect setColour:...]; [rect setWidth:...]; [rect setHeight:...]; This is short and readable. But observers will be notified after each setter. This could be a problem if intermediate states are not self- consistent and could also lead to unnecessary redrawing. In the general case, I might not even know who is observing. I guess it's safer to create a setColour:width:height: method in my NSManagedObject subclass that does: [self willAccessValueForKey:@colour]; [self willAccessValueForKey:@width]; [self setPrimitiveColour:...]; [self setPrimitiveWidth:...]; [self didAccessValueForKey:@width]; [self didAccessValueForKey:@colour]; Is this what I should be doing? I can see it getting ugly with more than 3 or so properties... ___ 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
Application Design Question
Hello everyone. I have a DVR (digital video recorder) program I wrote in Windows that I want to re-write on the Mac. And I wanted to get some ideas about how best to use Cocoa objects to make this program work as I'm still relatively new to Cocoa programming. The application has 2 modes, one is capturing video from a camera of any sort, a NTSC capture card, usb, ethernet, etc, that isn't a big deal since that'd just be its own thread. However I want to display the incoming video live on screen with the minimum of CPU loading as well as being able to scale the data and do some basic manipulations on it, perhaps including whats in Core Image. The incoming data is often 8-bit monochrome and needs to be scaled to 8-bit grey for screen display. The other mode is playing back a file, either frame by frame or playing back the video at a user settable frame rate. I'd like to be able to have multiple sets of both open at once. Another question related to this is what API set provides the fastest disk IO under Mac OS X? On the windows side I used FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags with the ReadFile/WriteFile API. My thoughts are perhaps NSDocument with NSView's that use Core Animation for displaying everything assuming there is a way to sequence bitmaps into Core Animation. But perhaps there is a better way? Also I might want to do secondary floating windows that display histograms or camera controls, etc. The file formats are a proprietary format and not related to Quicktime or Windows Media, etc. Thanks -Marek ___ 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
Re: Application Design Question
On Sep 4, 2009, at 4:55 PM, Marek Kozubal wrote: Another question related to this is what API set provides the fastest disk IO under Mac OS X? On the windows side I used FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags with the ReadFile/WriteFile API. The fastest will be the low-level POSIX I/O calls (open / write / etc.). To disable caching, call fcntl() using the F_NOCACHE operand. Try to read/write as much as you can in one call -- on the write side, the writev() function can be very useful. For details you might want to look into the Big Nerd Ranch Advanced Mac OS X Programming book, or for that matter, any book that covers Unix file I/O in depth. —Jens___ 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
re: core-data app design question
I have a question, or rather, I'm looking for advice, on the design of an application. Essentially I'm wanting to write a labbook-type application. My plan was to use core-data for the model. In the model will be an Entry entity. Each entry will have a one-to-one relationship to a Content entity. The Content entity will just (at the moment) contain a single attribute (data) which will be binary data. Implementing this on the Mac I planned to use NSTextView to provide a rich-text entry for the data attribute. Now comes the problem. I want to make a Cocoa Touch version of the app, and make then synchronize over Mobile me. The problem is I see no way to handle the NSAttributedString that will be stored in the data attribute on the iPhone. Does anyone have any advice as to how I might go about this? I was considering dropping back to plain text, but am loath to do this. Well, since you can't draw NSAttributedStrings on the iPhone, there isn't much point in archiving your data that way. You should use a platform neutral text run. You can write your own, which isn't hard for basic attributes, or you can use HTML instead, which you can draw on both platforms easily. Encoding your data this way is pushing the boundaries of violating MVC patterns by archiving UI information (NSTextView drawing information) into your model (database). That obviously doesn't work if the platform doesn't support NSTextView. - Ben ___ 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
Re: core-data app design question
On Aug 29, 2009, at 5:53 PM, Ben Trumbull trumb...@apple.com wrote: Encoding your data this way is pushing the boundaries of violating MVC patterns by archiving UI information (NSTextView drawing information) into your model (database). That obviously doesn't work if the platform doesn't support NSTextView. Beg to differ a but here, or at least point out that NSTextStorage is not just a view-layer class. It just doesn't happen to exist on the iPhone, so it isn't a suitable model class for this application. And that gets into hooking up field editors to your document's text storage vs. copying that text storage and changing it atomically. NSUndoManager support makes it very clear which you want to do. --Kyle Sluder ___ 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
core-data app design question
Dear list, I have a question, or rather, I'm looking for advice, on the design of an application. Essentially I'm wanting to write a labbook-type application. My plan was to use core-data for the model. In the model will be an Entry entity. Each entry will have a one-to-one relationship to a Content entity. The Content entity will just (at the moment) contain a single attribute (data) which will be binary data. Implementing this on the Mac I planned to use NSTextView to provide a rich-text entry for the data attribute. Now comes the problem. I want to make a Cocoa Touch version of the app, and make then synchronize over Mobile me. The problem is I see no way to handle the NSAttributedString that will be stored in the data attribute on the iPhone. Does anyone have any advice as to how I might go about this? I was considering dropping back to plain text, but am loath to do this. Best wishes, Martin Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson ___ 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
Re: core-data app design question
On Aug 28, 2009, at 8:37 AM, Martin Hewitson wrote: Dear list, I have a question, or rather, I'm looking for advice, on the design of an application. Essentially I'm wanting to write a labbook-type application. My plan was to use core-data for the model. In the model will be an Entry entity. Each entry will have a one-to-one relationship to a Content entity. The Content entity will just (at the moment) contain a single attribute (data) which will be binary data. Implementing this on the Mac I planned to use NSTextView to provide a rich-text entry for the data attribute. Now comes the problem. I want to make a Cocoa Touch version of the app, and make then synchronize over Mobile me. The problem is I see no way to handle the NSAttributedString that will be stored in the data attribute on the iPhone. Does anyone have any advice as to how I might go about this? I was considering dropping back to plain text, but am loath to do this. Best wishes, Martin If you have two entities with one-to-one relationships to each other you could probably just merge them into one entity. I have seen note taking applications that store the actual note content as an RTFD document on the file system and then, presumably, store a path to the document in the core data store. cheers 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Design Question
Fair enough. I guess what I'm wondering then is how do I handle the
following case. I have several loosely coupled properties which can
read somewhat like this.
(ProjectInstall *)projectInstall {
return [ProjectInstallController projectInstallWithProjectId:projectId];
}
And in some cases it's completely legit for the loose coupled
properties to return nil
What's the right way for this property to be KVO/KVC compliant? I
really do like bindings and believe that it's absolutely possible to
get it done right I'm just trying to figure it out.
Thanks for the input,
Bryan McLemore
Kaelten
On Thu, Aug 6, 2009 at 12:35 AM, Quincey
Morrisquinceymor...@earthlink.net wrote:
On Aug 4, 2009, at 11:35, Kaelten wrote:
I have an application I'm working on where I'm using mainly Bindings
for communicating with the UI, but I find myself in situations where
I'm not getting all the data updates to the UI.
These lack of updates seem to stem either from dependent keys, loose
coupling between objects, to-many relationships, and nullable
relationships.
I work around the first one mostly with
setKeys:triggerChangeNotificationsForDependentKey: (I'm targeting
10.4).
It's the other three cases that I'm having a slight issue with. One
thought I had is that I could craft notifications so that the loosely
coupled objects and nullable relationships can listen for something
that'd cause them to need to update.
It's all about KVO compliance. If you update your data model
KVO-compliantly, then its observers (e.g. the user interface) will notice
the changes.
The documentation isn't very clear, but the granularity of KVO compliance
isn't obvious. An *object* (an instance) is KVO-compliant for a *property*
(a string name) or its not. Typically, all objects of a class have the same
KVO-compliance for their properties, due their shared class implementation,
so it's reasonable to talk about the KVO compliance of a class for a given
property. If you have a lot of properties, you have a lot of compliance
issues to deal with.
So, it's not an issue of loose couplings, or to-many relationships or
nullable relationships -- they'll all work fine if the corresponding
properties are updated KVO-compliantly, and that has to be taken on a
case-by-case basis. Sorry.
If you want ask specifically about certain of the malfunctioning properties,
you might get answers you can adapt to the others. I just don't think
there's a general answer, except that it really does work, if you Do It
Right(tm).
___
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/kaelten%40gmail.com
This email sent to kael...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Design Question
On Aug 6, 2009, at 07:46, Kaelten wrote:
I guess what I'm wondering then is how do I handle the
following case. I have several loosely coupled properties which can
read somewhat like this.
(ProjectInstall *)projectInstall {
return [ProjectInstallController
projectInstallWithProjectId:projectId];
}
And in some cases it's completely legit for the loose coupled
properties to return nil
What's the right way for this property to be KVO/KVC compliant? I
really do like bindings and believe that it's absolutely possible to
get it done right I'm just trying to figure it out.
First, I say again, *properties* aren't KVO compliant. *Objects* are
KVO compliant (or not) for each of their properties. Your question
can't be answered without knowing what class implements
'projectInstall' -- and whether 'projectInstall' is a class or
instance method, since you dropped the + or -.
Assuming this is an instance method of a class named (say) Project,
which has an instance variable 'projectId', ask yourself what the
returned value depends on:
If 'projectId' changes, does that need to trigger an update of the
value of 'projectInstall' in its observers? (If not, 'projectInstall'
isn't really a property.) If so, and 'projectId' is itself a KVO-
compliant property, then you can use
setKeys:triggerChangeNotificationsForDependentKey: to set up a
dependency. If 'projectId' isn't a KVO-compliant property, you'll need
to trigger KVO notifications manually (using will/
didChangeValueForKey:@projectInstall) *wherever* your Project class
changes the value of projectId.
Does [ProjectInstallController projectInstallWithProjectId:projectId]
always return the same value for a given value of 'projectId'? If so,
there's nothing else to do. If not, then you need to make
'projectInstall' dependent on whatever affects the value returned by
ProjectInstallController. If you can't determine that, then again
'projectInstall' isn't really a property.
I have to add that it's a bit suspicious that your 'projectInstall'
property (of a data model object) apparently has to ask a controller
object for data. (Let's hope that 'projectInstallWithProjectId:' isn't
a factory method.) It's hard to know without more context, but this
suggests your MVC design mightn't be well-formed. If that's true,
you're likely to have deeper reasons for not being able to ensure KVO
compliance.
Finally, the question of whether 'projectInstall' sometimes returns
nil is irrelevant. That has nothing to do with the compliance of the
Project object.
___
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
Re: Design Question
On Aug 6, 2009, at 12:29 PM, Quincey Morris wrote: Finally, the question of whether 'projectInstall' sometimes returns nil is irrelevant. That has nothing to do with the compliance of the Project object. Except, check out Bug Fix in KVO's Dependency Mechanism in the Leopard Foundation Release Notes http://developer.apple.com/ReleaseNotes/Cocoa/Foundation.html#KVCKVO . The bug mentioned was fixed in Leopard, but since Bryan said he's targeting Tiger, he may be getting bit by it. Regards, Ken ___ 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
Design Question
I have an application I'm working on where I'm using mainly Bindings for communicating with the UI, but I find myself in situations where I'm not getting all the data updates to the UI. These lack of updates seem to stem either from dependent keys, loose coupling between objects, to-many relationships, and nullable relationships. I work around the first one mostly with setKeys:triggerChangeNotificationsForDependentKey: (I'm targeting 10.4). It's the other three cases that I'm having a slight issue with. One thought I had is that I could craft notifications so that the loosely coupled objects and nullable relationships can listen for something that'd cause them to need to update. Unfortunately, this is my first cocoa application and I'm working in a fairly sizable vacuum so any input you guys have would be greatly appreciated. Bryan McLemore Kaelten ___ 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
Re: Design Question
On Aug 4, 2009, at 11:35, Kaelten wrote: I have an application I'm working on where I'm using mainly Bindings for communicating with the UI, but I find myself in situations where I'm not getting all the data updates to the UI. These lack of updates seem to stem either from dependent keys, loose coupling between objects, to-many relationships, and nullable relationships. I work around the first one mostly with setKeys:triggerChangeNotificationsForDependentKey: (I'm targeting 10.4). It's the other three cases that I'm having a slight issue with. One thought I had is that I could craft notifications so that the loosely coupled objects and nullable relationships can listen for something that'd cause them to need to update. It's all about KVO compliance. If you update your data model KVO- compliantly, then its observers (e.g. the user interface) will notice the changes. The documentation isn't very clear, but the granularity of KVO compliance isn't obvious. An *object* (an instance) is KVO-compliant for a *property* (a string name) or its not. Typically, all objects of a class have the same KVO-compliance for their properties, due their shared class implementation, so it's reasonable to talk about the KVO compliance of a class for a given property. If you have a lot of properties, you have a lot of compliance issues to deal with. So, it's not an issue of loose couplings, or to-many relationships or nullable relationships -- they'll all work fine if the corresponding properties are updated KVO-compliantly, and that has to be taken on a case-by-case basis. Sorry. If you want ask specifically about certain of the malfunctioning properties, you might get answers you can adapt to the others. I just don't think there's a general answer, except that it really does work, if you Do It Right(tm). ___ 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
Re: BOOL takeStupidRoad = NO (search app design question)
Hello, David, there is nothing wrong with your aproach. For this amount of data and for its first version the program should be ok. However, if you find out later that your search needs to be faster/ consume less memory/work with more files, you will need to optimize the application. Note that this is the correct approach. First make the application work. Optimize later, when/if necessary. If you structure your application well (ObjectOriented design), then you will be able to switch new search code and snippet generation into application without changing the rest of application. This is the main and most important design issue - how to structure your application so you can improve it with as little work as possible. Search optimization can take many forms, from using SearchKit or some other search library to build your private index, or using Spotlight API, or some other search tool (such as programmatically running the command like 'grep' and parsing its output). The software will become more complicated, because the generation of snippets may or may not be supported by the search code you will use, so you may need to generate them yourself, separately from search. izidor On 21.3.2009, at 11:24, David Yamartino wrote: Hi All, I have a general design question. I'm going through the latest Hillegass and Kochan programming books for the purpose of writing a simple search app. I think I've figured out a way to do this, but having no experience in programming, I have no idea if my approach is good or bad. I'd rather not take the stupid road if I can avoid it, so I'm hoping someone may be able to set me straight before I go too far down the road. So if you're inclined to take a few minutes to consider what I've written below, I'd appreciate it. In any case, good luck with your projects, David *APPLICATION DESCRIPTION:* I have a library of about 1,500 text files, about 93 MB total. The application window opens with two views: left view shows the hierarchy of folders/files, and when you click on a file, the text of the file appears in the right view, where you can read, scroll, etc. The user inputs a term into the search field, and when the search is executed, the folders/files on the left view disappear and the view is repopulated with a new hierarchy showing only the folders/files where the search term appears. Below each file will be snippets of where the term appears within the text. Click on a snippet and the right view will show the entire text of the file zoomed to where the snippet appears. For example, if the search term is child education: *Book X* The *child education* conference focused on two age groups: 5-7 years, and 8-10 years. . . . because the *child* wasn't receiving the needed attention in her *education*, her parents decided . . . . . . and over the years the *child education* policy was broadened to include moral education and . . . *MY APPROACH*: I can load the text of the 1,500 files into 1500 NSStrings with something like stringWithContentsOfFile Then I can search the 1,500 NSStrings to locate the position of the search term within each string, then extract a range (including some words before and some words after) to make the snippets. Using rangeOfString NSMakeRange etc. *QUESTION:* Would this be a workable approach? Or is it a really stupid idea to have to load 93 MB of files into 1,500 NSStrings every time the program starts up? If not this approach, what would be more efficient? Thanks. ___ 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/ij.cocoadev%40gmail.com This email sent to ij.cocoa...@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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: BOOL takeStupidRoad = NO (search app design question)
Thanks, Izidor, for these suggestions. Regarding the Spotlight API, several people have suggested this, however my understanding is that Spotlight indexes at the file level - that is, it knows that the word perpendicular is contained in File X, File Y, and File Z. However, I need to know the exact 11 locations where the word appears in these files, which I don't think Spotlight does. Then again, I guess I could use Spotlight to locate the proper files, and then focus on them for finding the position of the words and then getting the words around them for the snippets, etc. OK - I'll do my best to proceed like this (or otherwise make it work) then optimize if needed. I really appreciate your help, David On Mon, Mar 23, 2009 at 8:08 PM, Izidor Jerebic ij.cocoa...@gmail.comwrote: Hello, David, there is nothing wrong with your aproach. For this amount of data and for its first version the program should be ok. However, if you find out later that your search needs to be faster/consume less memory/work with more files, you will need to optimize the application. Note that this is the correct approach. First make the application work. Optimize later, when/if necessary. If you structure your application well (ObjectOriented design), then you will be able to switch new search code and snippet generation into application without changing the rest of application. This is the main and most important design issue - how to structure your application so you can improve it with as little work as possible. Search optimization can take many forms, from using SearchKit or some other search library to build your private index, or using Spotlight API, or some other search tool (such as programmatically running the command like 'grep' and parsing its output). The software will become more complicated, because the generation of snippets may or may not be supported by the search code you will use, so you may need to generate them yourself, separately from search. izidor On 21.3.2009, at 11:24, David Yamartino wrote: Hi All, I have a general design question. I'm going through the latest Hillegass and Kochan programming books for the purpose of writing a simple search app. I think I've figured out a way to do this, but having no experience in programming, I have no idea if my approach is good or bad. I'd rather not take the stupid road if I can avoid it, so I'm hoping someone may be able to set me straight before I go too far down the road. So if you're inclined to take a few minutes to consider what I've written below, I'd appreciate it. In any case, good luck with your projects, David *APPLICATION DESCRIPTION:* I have a library of about 1,500 text files, about 93 MB total. The application window opens with two views: left view shows the hierarchy of folders/files, and when you click on a file, the text of the file appears in the right view, where you can read, scroll, etc. The user inputs a term into the search field, and when the search is executed, the folders/files on the left view disappear and the view is repopulated with a new hierarchy showing only the folders/files where the search term appears. Below each file will be snippets of where the term appears within the text. Click on a snippet and the right view will show the entire text of the file zoomed to where the snippet appears. For example, if the search term is child education: *Book X* The *child education* conference focused on two age groups: 5-7 years, and 8-10 years. . . . because the *child* wasn't receiving the needed attention in her *education*, her parents decided . . . . . . and over the years the *child education* policy was broadened to include moral education and . . . *MY APPROACH*: I can load the text of the 1,500 files into 1500 NSStrings with something like stringWithContentsOfFile Then I can search the 1,500 NSStrings to locate the position of the search term within each string, then extract a range (including some words before and some words after) to make the snippets. Using rangeOfString NSMakeRange etc. *QUESTION:* Would this be a workable approach? Or is it a really stupid idea to have to load 93 MB of files into 1,500 NSStrings every time the program starts up? If not this approach, what would be more efficient? Thanks. ___ 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/ij.cocoadev%40gmail.com This email sent to ij.cocoa...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com
Re: BOOL takeStupidRoad = NO (search app design question)
Then again, I guess I could use Spotlight to locate the proper files, and then focus on them for finding the position of the words and then getting the words around them for the snippets, etc. Exactly. However, for the amount of data you're talking about, just loading it up searching it is not unreasonable at all. -- Scott Ribe scott_r...@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice ___ 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
Re: BOOL takeStupidRoad = NO (search app design question)
Yes, thank you. So that's how I'll proceed. David -- On Tue, Mar 24, 2009 at 3:18 AM, Scott Ribe scott_r...@killerbytes.comwrote: Then again, I guess I could use Spotlight to locate the proper files, and then focus on them for finding the position of the words and then getting the words around them for the snippets, etc. Exactly. However, for the amount of data you're talking about, just loading it up searching it is not unreasonable at all. -- Scott Ribe scott_r...@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice ___ 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
BOOL takeStupidRoad = NO (search app design question)
Hi All, I have a general design question. I'm going through the latest Hillegass and Kochan programming books for the purpose of writing a simple search app. I think I've figured out a way to do this, but having no experience in programming, I have no idea if my approach is good or bad. I'd rather not take the stupid road if I can avoid it, so I'm hoping someone may be able to set me straight before I go too far down the road. So if you're inclined to take a few minutes to consider what I've written below, I'd appreciate it. In any case, good luck with your projects, David *APPLICATION DESCRIPTION:* I have a library of about 1,500 text files, about 93 MB total. The application window opens with two views: left view shows the hierarchy of folders/files, and when you click on a file, the text of the file appears in the right view, where you can read, scroll, etc. The user inputs a term into the search field, and when the search is executed, the folders/files on the left view disappear and the view is repopulated with a new hierarchy showing only the folders/files where the search term appears. Below each file will be snippets of where the term appears within the text. Click on a snippet and the right view will show the entire text of the file zoomed to where the snippet appears. For example, if the search term is child education: *Book X* The *child education* conference focused on two age groups: 5-7 years, and 8-10 years. . . . because the *child* wasn't receiving the needed attention in her *education*, her parents decided . . . . . . and over the years the *child education* policy was broadened to include moral education and . . . *MY APPROACH*: I can load the text of the 1,500 files into 1500 NSStrings with something like stringWithContentsOfFile Then I can search the 1,500 NSStrings to locate the position of the search term within each string, then extract a range (including some words before and some words after) to make the snippets. Using rangeOfString NSMakeRange etc. *QUESTION:* Would this be a workable approach? Or is it a really stupid idea to have to load 93 MB of files into 1,500 NSStrings every time the program starts up? If not this approach, what would be more efficient? Thanks. ___ 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
Design question: View with hell lot of drawing
Hi All, I need to display huge number of elements in NSView (1000-2000). These elements are generally made of high resolution image files with some fancy drawing around them. These elements may vary from size 300 X 270 to 4280 X 3500. First I made use of NSView's for elements, I abandoned the idea because I was supposed to connect some elements with lines, obviously line drawing was going behind the elements . Secondly I tried with CALayer's and I have a problem of GPU constraint for the resolutions I mentioned.(I tried optimizing, by only displaying required layer in the View's visible part ,that too didn't help much) Is there any other way of approach, or should I be making use of one of the ways I mentioned ? Any help is greatly appreciated Thanks Rajesh previous message to the list: subLayers - GPU - optimizing ___ 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
Re: Design question: View with hell lot of drawing
On 10/03/2009, at 7:39 PM, rajesh wrote: Is there any other way of approach, or should I be making use of one of the ways I mentioned ? Of course - just define a custom object that contains or manages each piece of content and draw them in one view. This is the classic approach and is probably the most scalable technique of all, since it incurs no overhead other than what you add. The simplest approach is just to hold all the objects in a list and when the view is updated, traverse the list and determine which objects need to be drawn. The view itself has methods to keep this to a minimum -needsToDrawRect: and -getRectsBeingDrawn:count: For large numbers of objects (1000, but YMMV) traversing the list testing for needs to be drawn itself becomes significant, in which case you'll need to consider alternative architectures such as binary search partitioning or R*-trees. My own DrawKit project includes classes for dealing with this problem. http://apptree.net/drawkit.htm (though right now the implementation in the current download is a bit buggy - I have a new version going out soon that fixes these issues). --Graham ___ 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
Re: Design question: View with hell lot of drawing
On Mar 10, 2009, at 1:39 AM, rajesh wrote: I need to display huge number of elements in NSView (1000-2000). These elements are generally made of high resolution image files with some fancy drawing around them. These elements may vary from size 300 X 270 to 4280 X 3500. First I made use of NSView's for elements, I abandoned the idea because I was supposed to connect some elements with lines, obviously line drawing was going behind the elements . Secondly I tried with CALayer's and I have a problem of GPU constraint for the resolutions I mentioned.(I tried optimizing, by only displaying required layer in the View's visible part ,that too didn't help much) Is there any other way of approach, or should I be making use of one of the ways I mentioned ? In addition to Graham's comments in a previous reply, I'd also suggest that, depending on what your view does, to generate a smaller thumbnail to represent the full-sized image. This both reduces your memory footprint as well as improving drawing speed. If the thumbnail size is dependent upon the view size, you could either invalidate your thumbnail cache when the view size changes or choose a maximum thumbnail size that you just scale appropriately. ___ 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
Re: Design Question
On Feb 12, 2009, at 9:50 AM, David Blanton wrote: Do I understand correctly that if a layer with explicit animations is hidden the animation is still running? Yes, animations always run, regardless of the hidden state of a layer (hidden is just another render attribute). -- David Duncan Apple DTS Animation and Printing ___ 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
Re: Design Question
So besides hiding a layer I should also removeAnimationForKey: Thanks! On Feb 12, 2009, at 11:16 AM, David Duncan wrote: On Feb 12, 2009, at 9:50 AM, David Blanton wrote: Do I understand correctly that if a layer with explicit animations is hidden the animation is still running? Yes, animations always run, regardless of the hidden state of a layer (hidden is just another render attribute). -- David Duncan Apple DTS Animation and Printing David Blanton ___ 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
First responder design question. Are controllers in the chain?
I'm just starting to delve into the first responder chain to handle menu actions. My conceptual understanding of MVC is that the controller is the one who determines what to do with actions. When someone wants to do something the controller is told by a control in the view, it updates the model and in turn updates the display. I've been conceptually thinking of the document as part of the model. The first responder chain in the document architecture goes through the view hierarchy and checks the document. It doesn't go through the controllers. I'm not sure how it would even know about them. But in any case, the actions that I want the menu to invoke are on my controllers. I want them invoked in the same way that I have buttons in the UI which send actions to the controller. Given that the default first responder chain does NOT include controllers... architecturally, what is the best approach to get the actions invoked? Options include: 1. I can add methods to my Document to forward the messages to the controller. But this seems to confuse the model and controller. Now I'd have the model receiving the action, sending it to the controller which may in turn send it back to the model. 2. Subclass something in the view so that it forwards the message to the controller. Maybe an NSWindow delegate? I've been trying to avoid subclassing view classes if I don't need to. So far I haven't had to subclass any of them. 3. Modify the first responder chain and specifically add one or more controllers to the chain. Where would be the appropriate place to modify the first responder chain? Thanks ___ 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 [EMAIL PROTECTED]
Re: Design Question: Bindings Custom Views
Cocoa Design Patterns Chapter 29, Controllers, contains an MVC solution to exactly the problem Oleg Krupnov describes. The chapter presents a relatively simple MVC MYShapeDraw application. The chapter leads the reader through the step by step process of re-inventing NSArrayController as part of the MYShapeDraw application. The goal is to highlight the rationale and use pattern for array controller and other controllers. One of the reasons to use an array controller as a mediator between model objects and views is precisely so that it's easy to have multiple different views and potentially different models. Therefore, the application provides multiple views. The example even discusses sharing selection information by multiple views or letting each view have a different notion of the current selection. The application also uses the Associative Storage pattern from chapter 19 to enable any view to store whatever extra information it wants along with model objects. Categories are used to separate view related code from the model code. Apple uses this approach in several places to add view layer capabilities to model layer objects. See NSString and NSStringAdditions. ___ 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 [EMAIL PROTECTED]
Re: Design Question: Bindings Custom Views
Sorry. When I posted about the problem Oleg Krupnov describes, I wasn't caught up on my reading of the list. The VC MYShapeDraw application I describe is a drawing application and not related to image thumbnail caching. Of course, the pattern is general and applicable to image thumbnail caching. ___ 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 [EMAIL PROTECTED]
Re: Design Question: Bindings Custom Views
Parts of your first question remind me of a situation that I had. Erik Buck gave me some great advice and part of it was the following: If you are worried about adding drawing code to a Model object, add the drawing code in a category of the model object* and maintain the category implementation in the View subsystem. *I changed the words he used here because he used the name of my specific class and I wanted to make it more readable in the general case. This will let you put a category into every view that you want to so that your model objects get handled correctly for each view. This may be indeed a good idea to use categories for this purpose. Is it what everybody is using? I have only one problem with this approach: As I mentioned before, I need to add custom-view specific instance variables (states) to the model object's category. The Objective-C categories do not allow adding instance variables, only methods I am considering to create a dictionary owned by the custom view, containing state objects keyed by model object unique ID. This is a kind of surrogate of subclassing the model objects inside the custom view. I am not sure this is a good idea though. Are there other approaches? ___ 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 [EMAIL PROTECTED]
Re: Design Question: Bindings Custom Views
Yes, you are correct. I am looking not to break MVC and also get the correct implementation of binding in a custom view Just an example: I had a graphic application that drawed some inserted shapes. The shape itself is a part of the model, the color of the shape, too. But when the user selects a shape (symbol), the color should change. So the drawing of the shape depends on a view property. I think, this is the core of your problem. Selection may not be a good example, because it is a global property of the view, among all objects in the view, whereas I am talking about states *per each object in the view. Such state properties become particularly indispensable for drawing, because drawRect message is called asynchronously, i.e. in the next event loop, not in direct response to the binding's KVO message. The other case is when I need, for performance reasons, to associate some view-specific cached data with an object in the view, to avoid recreating it each time I need the data to respond to the binding's KVO message. In other words, I need a way to associate additional custom-view-specific properties with model object, without adding them as transitive properties to the model. What is the best way to do this? Or maybe your point is that this is a bad idea at all and such problem should not arise, and I need to include everything in the model? What is the standard workaround suggested in Cocoa? I solved it by returning only bezier paths and colors from the model. So the shape itself (model) is still a part of the model, but the drawing (depending on the view) is done inside the view. (Simply by stroking the paths.) It is not completely clear how this would help me to resolve the above problem. It is not a problem for me to store the bezier paths and colors in the model. But what about some volatile custom-view-specific states that have nothing to do with the model? The other completely different design I am also considering is to create and bind a subview object for each model object. By subview I mean just a subclass of NSObject that is bound to its model counterpart. It could work like this: The custom NSView observes its NSTreeController and when a new child model object is created, the custom NSView creates the corresponding subview object (All subview objects are owned by the custom NSView) and binds it to the model object programmatically. When the model object is changed or removed, its subview counterpart responds correspondingly. In this manner I could hold all the view-specific states and cache data in the subview object. What do you think? On Thu, Aug 28, 2008 at 11:35 AM, Negm-Awad Amin [EMAIL PROTECTED] wrote: Am Do,28.08.2008 um 10:15 schrieb Oleg Krupnov: Parts of your first question remind me of a situation that I had. Erik Buck gave me some great advice and part of it was the following: If you are worried about adding drawing code to a Model object, add the drawing code in a category of the model object* and maintain the category implementation in the View subsystem. *I changed the words he used here because he used the name of my specific class and I wanted to make it more readable in the general case. This will let you put a category into every view that you want to so that your model objects get handled correctly for each view. This may be indeed a good idea to use categories for this purpose. Is it what everybody is using? I have only one problem with this approach: As I mentioned before, I need to add custom-view specific instance variables (states) to the model object's category. The Objective-C categories do not allow adding instance variables, only methods I am considering to create a dictionary owned by the custom view, containing state objects keyed by model object unique ID. This is a kind of surrogate of subclassing the model objects inside the custom view. I am not sure this is a good idea though. Are there other approaches? If I understood you correct, you think, that you fear a voilation of the MVC pattern. Correct? Think about some points: - sometimes the shape or something like this is a true part of the model. Think about predefined shapes and so on. So there is nothing wrong in storing that informtion in the model. - Can you isolate the shape-part (model) from the drawing part (obviously depending on view states)? Just an example: I had a graphic application that drawed some inserted shapes. The shape itself is a part of the model, the color of the shape, too. But when the user selects a shape (symbol), the color should change. So the drawing of the shape depends on a view property. I think, this is the core of your problem. I solved it by returning only bezier paths and colors from the model. So the shape itself (model) is still a part of the model, but the drawing (depending on the view) is done inside the view. (Simply by stroking the paths.) Cheers, Amin
Re: Design Question: Bindings Custom Views
Okay, I – hopefully – understand you now: You have a view with some (model) objects displayed. There is another view (potentially or really?) that can display these objects, too The additional attributes are specific for each displayed object and each view? Correct? (There is a german phrase: The hope dies last) So you have an n-to-m relationship between between objects and views. And you have additional attributes for each of these relationship instances. ( … for every concrete relationship.) Yes, IMHO it is a good idea to personalize (bad translation, I do not know a better one) this relationship and represent it with instances of a special class. I did something similiar (if I understood you correct) inside the model layer (this does not really matter here) in a lawfirm application. I had the problem, that I had an n-to-m relationship between files and clients. On each instance of the relationship I needed some additional attributes. (Something like the state of the client related to this file.) I broke the n-to-m relationship and modelled a new entity FileClient that holds the additional attributes. Of course this was easier to me, because it happens solely inside the model layer. I did not have to register and handle observations. But I think, that it is the same approach in the core. Maybe this helps … Cheers, Amin Am Do,28.08.2008 um 11:06 schrieb Oleg Krupnov: Yes, you are correct. I am looking not to break MVC and also get the correct implementation of binding in a custom view Just an example: I had a graphic application that drawed some inserted shapes. The shape itself is a part of the model, the color of the shape, too. But when the user selects a shape (symbol), the color should change. So the drawing of the shape depends on a view property. I think, this is the core of your problem. Selection may not be a good example, because it is a global property of the view, among all objects in the view, whereas I am talking about states *per each object in the view. Such state properties become particularly indispensable for drawing, because drawRect message is called asynchronously, i.e. in the next event loop, not in direct response to the binding's KVO message. The other case is when I need, for performance reasons, to associate some view-specific cached data with an object in the view, to avoid recreating it each time I need the data to respond to the binding's KVO message. In other words, I need a way to associate additional custom-view-specific properties with model object, without adding them as transitive properties to the model. What is the best way to do this? Or maybe your point is that this is a bad idea at all and such problem should not arise, and I need to include everything in the model? What is the standard workaround suggested in Cocoa? I solved it by returning only bezier paths and colors from the model. So the shape itself (model) is still a part of the model, but the drawing (depending on the view) is done inside the view. (Simply by stroking the paths.) It is not completely clear how this would help me to resolve the above problem. It is not a problem for me to store the bezier paths and colors in the model. But what about some volatile custom-view-specific states that have nothing to do with the model? The other completely different design I am also considering is to create and bind a subview object for each model object. By subview I mean just a subclass of NSObject that is bound to its model counterpart. It could work like this: The custom NSView observes its NSTreeController and when a new child model object is created, the custom NSView creates the corresponding subview object (All subview objects are owned by the custom NSView) and binds it to the model object programmatically. When the model object is changed or removed, its subview counterpart responds correspondingly. In this manner I could hold all the view-specific states and cache data in the subview object. What do you think? On Thu, Aug 28, 2008 at 11:35 AM, Negm-Awad Amin [EMAIL PROTECTED] wrote: Am Do,28.08.2008 um 10:15 schrieb Oleg Krupnov: Parts of your first question remind me of a situation that I had. Erik Buck gave me some great advice and part of it was the following: If you are worried about adding drawing code to a Model object, add the drawing code in a category of the model object* and maintain the category implementation in the View subsystem. *I changed the words he used here because he used the name of my specific class and I wanted to make it more readable in the general case. This will let you put a category into every view that you want to so that your model objects get handled correctly for each view. This may be indeed a good idea to use categories for this purpose. Is it what everybody is using? I have only one problem with this approach: As I mentioned before, I need to add custom-view
Re: Design Question: Bindings Custom Views
On Aug 28, 2008, at 11:06 AM, Oleg Krupnov wrote: In other words, I need a way to associate additional custom-view-specific properties with model object, without adding them as transitive properties to the model. What is the best way to do this? Or maybe your point is that this is a bad idea at all and such problem should not arise, and I need to include everything in the model? What is the standard workaround suggested in Cocoa? Hi Oleg, I think there are times when it's appropriate to have wrapper objects - that are view related - for your model objects. In an image browser, it's likely that there is a thumbnail object that draws image objects. So maybe your custom view creates thumbnails for the shapes it needs to draw and keeps the view-related properties and states in those objects - instead of adding them to the shape objects themselves? It's a little crude - but from what I can understand about your problem - it could be a place for you to start separating the model and view in your design. HTH, Cathy ___ 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 [EMAIL PROTECTED]
Re: Design Question: Bindings Custom Views
I think there are times when it's appropriate to have wrapper objects - that are view related - for your model objects. In an image browser, it's likely that there is a thumbnail object that draws image objects. Yeah, maybe view-related wrapper objects for model objects is the right term. In your image browser example, this problem sounds as follows: where to store the cached thumbnail images, to avoid re-creating them anew in each drawRect call? Also, if a thumbnail is in process of dragging inside the custom view, where to save the flag that the thumbnail should be highlighted, the next time we draw it in drawRect? I thought this kind of problem should be well-known and commonplace among Cocoa developers... So maybe your custom view creates thumbnails for the shapes it needs to draw and keeps the view-related properties and states in those objects - instead of adding them to the shape objects themselves? It's a little crude - but from what I can understand about your problem - it could be a place for you to start separating the model and view in your design. I am not sure I understood this phrase. Why is it crude? Anyway, I am looking to solve the problem in the standard way, not reinvent anything. On Thu, Aug 28, 2008 at 1:03 PM, Cathy Shive [EMAIL PROTECTED] wrote: On Aug 28, 2008, at 11:06 AM, Oleg Krupnov wrote: In other words, I need a way to associate additional custom-view-specific properties with model object, without adding them as transitive properties to the model. What is the best way to do this? Or maybe your point is that this is a bad idea at all and such problem should not arise, and I need to include everything in the model? What is the standard workaround suggested in Cocoa? Hi Oleg, HTH, Cathy ___ 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 [EMAIL PROTECTED]
Re: Design Question: Bindings Custom Views
On 28 Aug 2008, at 6:15 pm, Oleg Krupnov wrote: I have only one problem with this approach: As I mentioned before, I need to add custom-view specific instance variables (states) to the model object's category. The Objective-C categories do not allow adding instance variables, only methods I am considering to create a dictionary owned by the custom view, containing state objects keyed by model object unique ID. This is a kind of surrogate of subclassing the model objects inside the custom view. I am not sure this is a good idea though. Are there other approaches? This doesn't sound, er... sound. What custom-view specific variables are you talking about? If there really are variables that are part of the view's state, then they should be part of the view. If they are part of the model's state they should be part of the model. Or perhaps they are really neither and should in fact be part of a controller that mediates between one and the other. I've not come across the need to do what you're apparently leaning towards when using a conventional MVC approach. Maybe a bit more context regarding your particular needs would help. cheers, Graham ___ 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 [EMAIL PROTECTED]
Re: Design Question: Bindings Custom Views
On 28 Aug 2008, at 8:26 pm, Oleg Krupnov wrote: In your image browser example, this problem sounds as follows: where to store the cached thumbnail images, to avoid re-creating them anew in each drawRect call? Also, if a thumbnail is in process of dragging inside the custom view, where to save the flag that the thumbnail should be highlighted, the next time we draw it in drawRect? I thought this kind of problem should be well-known and commonplace among Cocoa developers... BTW, for some reason my feed from the list was delayed by several hours and only just came unstuck, so it seems you've had some response on this already I didn't know about. In which case my first response probably isn't all that useful. Regarding the above though, if this is similar to your situation - what's really wrong with model objects caching a thumbnail? Being a slave to MVC is going to lead to suboptimal solutions just as ignoring MVC altogether is going to be. The cached thumbnail has to be stored somewhere, right? Where, doesn't really matter. So if a model object has a -thumbnail method that returns the thumbnail when you need it, what's wrong with that? The thumbnail doesn't need to end up permanently stored by the model when archived, just created lazily when required. If the model object is the best object to make and cache that thumbnail (i.e. it has all the state information to hand to do so) why not let it? A view that displays the thumbnail can then just request it directly from the object in question instead of going round the houses to generate a thumbnail simply to avoid the model object getting its hands dirty. Some may feel differently but I don't see that this violates MVC in any significant way and it's much simpler. An example from my DrawKit project - a style object is part of the model in that it represents a number of combined graphical properties of a drawn object. But a UI that deals in styles will often want a small thumbnail or icon to preview the style to the user. So my style objects handle that as well - they implement an -image method. Internally they also create it lazily and cache it for efficiency, but none of that really impacts the integrity of the model in any way. If it makes things feel better, you could put these methods into a category (I don't in this case). For the cache I use a statically declared dictionary within the -image method so that a) I don't need ivars in my style objects to store it and b) the static variable is independent and invisible to anything other than that specific method. (If this is what you were alluding to originally then I may have misunderstood - this seems a reasonable approach to me and works a treat). What I definitely don't do however is pass a view reference to the model object at any point - the -image method returns an image of that model object but it makes no assumptions about its use nor tailors its image generation according to the type of view. If you need to parameterise what a method like this does, do it in the abstract and let the caller/client decide what parameters to pass for its needs. Regarding selection of objects, that isn't part of the model state per se. You probably want to avoid having a is selected flag in your model object. However, it's often useful to let an object decide for itself what graphical form a selection highlight should take. So why not simply pass the is selected flag as a parameter to its draw method? When your view's -drawRect: is called, something is going to have to iterate over the objects and draw them. At that point you can determine if an object is selected or not and pass the flag as appropriate. The easiest way to handle selection that I've found is just to maintain a set of the the objects that are selected. To select an object, add it to this set. Then when drawing you can test for membership of this set and pass the flag to the draw method of the object. This is the way I did it in DrawKit and haven't discovered any obvious downside to it. It also fits in with bindings since you already have a list of the selection at your disposal at all times. The owner of the selection set could be the view but more likely it's part of a controller - depends really on whether you conceptually think of the selection as pertaining to just one view or to be the same across several. However, by passing the selected flag to the object when you draw it, you can do it either way without tying yourself down. Any help? Graham ___ 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 [EMAIL
Re: Design Question: Bindings Custom Views
On Aug 28, 2008, at 12:26 PM, Oleg Krupnov wrote: I think there are times when it's appropriate to have wrapper objects - that are view related - for your model objects. In an image browser, it's likely that there is a thumbnail object that draws image objects. Yeah, maybe view-related wrapper objects for model objects is the right term. In your image browser example, this problem sounds as follows: where to store the cached thumbnail images, to avoid re-creating them anew in each drawRect call? Also, if a thumbnail is in process of dragging inside the custom view, where to save the flag that the thumbnail should be highlighted, the next time we draw it in drawRect? You can go about this several ways. the crude way ;) is to have a thumbnail for each image that needs to be drawn and have the thumbnail cache a bitmap (maybe two or three different sized bitmaps for different zoom levels) for each image. So the thumbnail just creates them once and then keeps them around as long as the image is on the screen for quick drawing. A less crude way is to implement some type of caching system - so, if the images are drawn in several views at the same time, all the views can share a centralized cache of bitmaps. As far as the view keeping states like which objects need to be highlighted, the view can set a isHighlighted flag in a thumbnail when it is selected, so the thumbnail can draw itself differently, or the view can keep track of the selected image indexes and draw selection highlights itself. If you look at the design of NSTableView, it keeps track of which row indexes are selected and draws each highlight right before it draws the cells. If you are customizing the NSCell drawing in a table view, the cell object can check if it isHighlighted and adjust its drawing based on that. The return value of isHighlighted is something that the view determines for the cell. I thought this kind of problem should be well-known and commonplace among Cocoa developers... I think this is more of a general interface widget design problem than a Cocoa problem. Cocoa developers get this kind of GUI behavior out of the box - NSTableView, IKImageBrowser, etc., so it won't come up unless you're doing something very custom - as I'm guessing you are. Looking at the API for these classes can certainly lead you in the right direction for designing your own custom views, if you're looking for the Cocoa way to do it. Also, I have to ask, but is it possible for you to use a pre-made object like an NSOutlineView for your UI? So maybe your custom view creates thumbnails for the shapes it needs to draw and keeps the view-related properties and states in those objects - instead of adding them to the shape objects themselves? It's a little crude - but from what I can understand about your problem - it could be a place for you to start separating the model and view in your design. I am not sure I understood this phrase. Why is it crude? Anyway, I am looking to solve the problem in the standard way, not reinvent anything. The reason I say it's crude is because what I'm suggesting to you is to have your view make a separate thumbnail object for each model object you need to draw. You can use this object to cache things and to keep track of states of each individual object for the view. It will work well as a way to keep the view related properties out of your model. This wrapper class will also make the needs of your view very clear. Eventually, you can evolve the design of your view so that it can handle all of the states, positioning, hit tests, caching, etc. itself, maybe eliminating the need for a wrapper thumbnail class altogether. I usually start with the most simple, or crude (maybe that was the wrong word ;)) solution and evolve the design from there. Again, there is no standard Cocoa way to design a custom view like this - but taking a look at how some of the comparable Cocoa GUI widgets are implemented can give you some good hints. I've learned tons from NSTableView - it's a very flexible design and can be used to display any model object you can throw at it. Look at how NSTableView and the IKImageBrowser use delegate and data source designs and how they work with cells - their thumbnails - to draw. If you can use one of these widgets instead of implementing your own with very similar behaviors, that would be the best solution - but I certainly understand that there are types of interactions that are very custom and then you need to roll your own - but even in this case you can use NSTableView or IKImageBrowser for inspiration. http://developer.apple.com/documentation/GraphicsImaging/Reference/IKImageBrowserView/IKImageBrowserView_Reference.html#/ /apple_ref/occ/cl/IKImageBrowserView
Re: Design Question: Bindings Custom Views
Grahaam Cox wrote on 2008-08-28 13:11:47: Regarding the above though, if this is similar to your situation - what's really wrong with model objects caching a thumbnail? Being a slave to MVC is going to lead to suboptimal solutions just as ignoring MVC altogether is going to be. The cached thumbnail has to be stored somewhere, right? Where, doesn't really matter. So if a model object has a -thumbnail method that returns the thumbnail when you need it, what's wrong with that? The thumbnail doesn't need to end up permanently stored by the model when archived, just created lazily when required. If the model object is the best object to make and cache that thumbnail (i.e. it has all the state information to hand to do so) why not let it? A view that displays the thumbnail can then just request it directly from the object in question instead of going round the houses to generate a thumbnail simply to avoid the model object getting its hands dirty. Some may feel differently but I don't see that this violates MVC in any significant way and it's much simpler. Your model objects could be re-used somewhere that AppKit isn't available or where it's unnecessary and perhaps even inappropriate to keep NSImages around; your command-line interface to the model probably won't need them, for instance. As such, following the Decorator pattern by having an object which does appkit-can-draw-this and has-a model object promotes re-use of the model. It also keeps all of your AppKit code in the view, so when you need an other-ui-framework-which-I-will-not-specify-can-draw-this object, you don't have to go hunting around for all that drawing code. As others have pointed out if you don't need extra ivars, or don't mind jumping through a hoop to get them, you can add a category to the model class which is decorating via ObjC magic. It still lets you separate the UI code into the view package, but also means you directly use the model class. An example of that approach is NSAttributedString(AppKitAdditions). Cheers, Graham. -- Graham Lee Senior Macintosh Software Engineer, Sophos Tel: 01235 540266 (Direct) Web: http://www.sophos.com Sophos - Security and Control Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 348 3873 20. ___ 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 [EMAIL PROTECTED]
Re: Design Question: Bindings Custom Views
Thanks, that mostly answers my question, finally. And the short answer is No :). There is no standard Cocoa way of doing this and it's up to me how to implement it. I just wanted to make sure I was not reinventing the wheel. You are correct in suspecting me in a kind of MVC purism (typical for a newbie :). Indeed, I used to understand the MVC pattern that the model should be strictly separated from the views and inherently assume a one-to-many relationship between the model and the views. It means that the model should not include properties and messages that are view-specific, because the number and kind of views is a black box for the model. The model might have a message for creating thumbnails, but it should not include a thumbnail ivar, because there can be two views of the same model, each requiring thumbnails of different kind. By adding ivars and messages that every view in the world might need will result in what is called fat interface for the model. The encapsulation becomes poor and unnecessary dependancies are introduced. It may work well at the beginning for it seems simple, but it may fire back and require refactoring as the program grows more complex. Your solution with the static dictionary looks similar to what I had in mind, except that I intended this dictionary to be owned by the custom NSView and not be static(I don't need different shapes to share the same thumbnails, each one is unique). By keying in the model objects pointers or their unique IDs, I could retrieve view-specific data from the dictionary. I could even wrap that data together with the messages for drawing and hit testing, so that I don't even have to use categories on model objects. Perhaps I will stick to this solution. Thanks! On Thu, Aug 28, 2008 at 3:11 PM, Graham Cox [EMAIL PROTECTED] wrote: On 28 Aug 2008, at 8:26 pm, Oleg Krupnov wrote: In your image browser example, this problem sounds as follows: where to store the cached thumbnail images, to avoid re-creating them anew in each drawRect call? Also, if a thumbnail is in process of dragging inside the custom view, where to save the flag that the thumbnail should be highlighted, the next time we draw it in drawRect? I thought this kind of problem should be well-known and commonplace among Cocoa developers... BTW, for some reason my feed from the list was delayed by several hours and only just came unstuck, so it seems you've had some response on this already I didn't know about. In which case my first response probably isn't all that useful. Regarding the above though, if this is similar to your situation - what's really wrong with model objects caching a thumbnail? Being a slave to MVC is going to lead to suboptimal solutions just as ignoring MVC altogether is going to be. The cached thumbnail has to be stored somewhere, right? Where, doesn't really matter. So if a model object has a -thumbnail method that returns the thumbnail when you need it, what's wrong with that? The thumbnail doesn't need to end up permanently stored by the model when archived, just created lazily when required. If the model object is the best object to make and cache that thumbnail (i.e. it has all the state information to hand to do so) why not let it? A view that displays the thumbnail can then just request it directly from the object in question instead of going round the houses to generate a thumbnail simply to avoid the model object getting its hands dirty. Some may feel differently but I don't see that this violates MVC in any significant way and it's much simpler. An example from my DrawKit project - a style object is part of the model in that it represents a number of combined graphical properties of a drawn object. But a UI that deals in styles will often want a small thumbnail or icon to preview the style to the user. So my style objects handle that as well - they implement an -image method. Internally they also create it lazily and cache it for efficiency, but none of that really impacts the integrity of the model in any way. If it makes things feel better, you could put these methods into a category (I don't in this case). For the cache I use a statically declared dictionary within the -image method so that a) I don't need ivars in my style objects to store it and b) the static variable is independent and invisible to anything other than that specific method. (If this is what you were alluding to originally then I may have misunderstood - this seems a reasonable approach to me and works a treat). What I definitely don't do however is pass a view reference to the model object at any point - the -image method returns an image of that model object but it makes no assumptions about its use nor tailors its image generation according to the type of view. If you need to parameterise what a method like this does, do it in the abstract and let the caller/client decide what parameters to pass for its needs. Regarding
Design Question: Bindings Custom Views
I am building a custom view that can display and edit some polymorphic objects. Furthermore, the objects can be composite, i.e. contain child objects hierarchically. Now I want to bind this custom view to the model through a controller (NSTreeController in my case). In the examples I have seen (GraphicsBindings, Sketch), the custom view, when it needs to draw objects or hit test objects or whatever else, it queries the controller for the array of model objects and sends them the corresponding message draw, hitTest etc. defined in the model interface. Is this actually the design everybody is using? IMHO such design introduces an implicit dependency between the view and the model. What if I want to have two or more views to view the model objects? I would have to have drawInView1, drawInView2 etc. messages in each model object's interface. Isn't it better to have the draw and hitTest messages encapsulated in the custom view's interface instead of the model objects (perhaps using the Visitor pattern to account on the object polymorphism)? This is my first question. Here's the second question. None of the mentioned two designs allow the custom view to add view-specific state to the model objects it displays or edits, in other words, the custom view, being a single long and flat object, treats the model objects as stateless objects. When the custom view becomes quite complex, it may be the case that the model objects need to have some transient states specific to this custom view only and therefore not included to the main model. For example, a model object displayed in the custom view can be expanded or collapsed which in no way affects the model or the other views of the model, so this property should not be included to the properties (even transient) of the model, to avoid (again) implicit dependencies between model and views. For this purpose, before I switched to using Cocoa bindings, I would create a view object counterpart for each model object displayed and edited in the custom view, and bind each pair of such counterparts to observe each other (manually using a technique that reminds KVO). The view objects encapsulate the draw and hitTest messages polymorphically, and also can have a state associated with the model object in context of the custom view. In addition, with such design, the custom view can be used independently on the model - even if there is no model and controller, you can still use the custom view by manipulating its unbound view objects. So the second question is - whether such design is good or bad and implementable in context of Cocoa bindings? (I wonder if it is possible to bind each model object to a view object without too much manual glue code). If not, how would you work around the mentioned problem? ___ 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 [EMAIL PROTECTED]
Design Question: Pro Cons of KVC/KVO
I need to make the design decision regarding how the model and the views will be kept in sync with each other. Namely: - I can use key-value coding and observing (KVC and KVO) - I can use bindings (not sure if it's really different from the KVC/KVO) - I can write the glue code myself The concept of KVC/KVO is new to me. I have been looking at the Sketch sample (a kind of application I am building myself too), which is based on KVC/KVO, and I have found that the use of KVC/KVO makes the program very unreadable and clumsy (like C++ COM code in Windows, you know), because of the generic messages and hidden dependencies. I suspect that it could be way easier, when a property's value changes, to just explicitly send a concise and clearly named message to the subscribed objects, than try to fit into the over-generalized model of KVC/KVO for the sake of skipping a few lines of code. And I still have to subscribe objects to objects with KVC/KVO, don't I? Does anyone actually use KVC/KVO? What is your experience? Any pros/cons, opinions and best practices would be appreciated. Thanks ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Am Do,21.08.2008 um 08:58 schrieb Oleg Krupnov:
I need to make the design decision regarding how the model and the
views will be kept in sync with each other. Namely:
- I can use key-value coding and observing (KVC and KVO)
- I can use bindings (not sure if it's really different from the KVC/
KVO)
At least it isn't, since a binding registers KVO and uses KVC for data
retrievel.
- I can write the glue code myself
The concept of KVC/KVO is new to me. I have been looking at the Sketch
sample (a kind of application I am building myself too), which is
based on KVC/KVO, and I have found that the use of KVC/KVO makes the
program very unreadable and clumsy (like C++ COM code in Windows, you
know), because of the generic messages and hidden dependencies.
There is no magic. IMHO, it makes the code more readable, beause the
dependencies are not central, but encapsulated.
I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,
This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:
I think, you want to say, that if one changes a property, he sends a
message to a central MVC server, which distributes update messages.
Correct? Why?
if you want to have one method per synchronized property, use a
NSString instance as context and simply do that:
// Typed in mail.app, simple example
- observeValueForKeyPath:(NSString*)keyPath ofObject:
(id)observedObject change:(NSDictionary*)change context:(void*)context
{
NSString* updateMethode = [NSString stringWithFormat.@update%@,
context]; // I didn't care about upper case to keep it simple for
demonstration
SEL selector = NSSelectorFromString( updateMethod );
if( [self respondsToSelector:selector] ) {
[self performSelector:selector];
}
}
This will call a method with the name updateSize, if you set @size
as the context at registration.
But: Why?
Cheers,
Amin
than try to fit into the over-generalized
model of KVC/KVO for the sake of skipping a few lines of code. And I
still have to subscribe objects to objects with KVC/KVO, don't I?
Does anyone actually use KVC/KVO? What is your experience? Any
pros/cons, opinions and best practices would be appreciated.
Thanks
___
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/negm-awad%40cocoading.de
This email sent to [EMAIL PROTECTED]
Amin Negm-Awad
[EMAIL PROTECTED]
___
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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,
This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:
Then how is it better than manual glue code?
I think, you want to say, that if one changes a property, he sends a message
to a central MVC server, which distributes update messages. Correct? Why?
No. Actually, the alternative approach that I kept in mind was that
each model object maintains an array of observers (like delegates or
just objects with a declared protocol) to all of which the
corresponding message is sent each time a property of the model object
changes.
For example,
idMyModelObjectObserver observer;
MyModelObject* myModelObject;
// subscribe observer
[myModelObject addObserver: observer];
// set some prop
[myModelObject setSomeProp:someValue];
@interface MyModelObject
{
NSMutableArray* m_observers;
id m_someProp;
}
@end
@implementation MyModelObject
- (void)addObserver:(idMyModelObjectObserver) observer
{
[m_observers addObject:observer];
}
- (void)setSomeProp:(id)newValue
{
// save new value
m_someProp = newValue;
// notify observers
idMyModelObjectObserver observer = nil;
for (observer in m_observers)
{
[observer somePropChanged];
}
}
@end
Is there something terribly wrong with this approach? The dependencies
are encapsulated. In addition, it seems that this approach gives me
more flexibility, say, if newValue is invalid, it can be rejected. Or,
for instance, when the entire MyModelObject gets removed from its
parent model object - in this case there is no property actually
modified, instead, a mutator message is received by the model, but the
observers still need to be notified. Can KVC/KVO monitor the contents
of an array of model objects? And so on. Even though KVC/KVO may
handle these cases too, my intuition tells me there can be cases when
the flexibility of KVC/KVO may run short compared to the manual code.
Anyway, even if I assume that KVC/KVO is at least not worse than
manual code, I don't see any real benefit so far. Except that it
allows me to get the scripting support for free (but I'd rather like
the scripting to be separate thing and not get in the way of the model
objects).
Could someone please try to explain me the rationale behind KVC/KVO
once again? :) Thanks
___
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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Am Do,21.08.2008 um 15:22 schrieb Oleg Krupnov:
I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,
This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:
Then how is it better than manual glue code?
1. You do not have to manage a list of observes. this is done by cocoa.
2. cocoas implementation is faster than everything you would program.
3. Less Coding for you
4. Compliance with cocoa concepts
Enough?
I think, you want to say, that if one changes a property, he sends
a message
to a central MVC server, which distributes update messages.
Correct? Why?
No. Actually, the alternative approach that I kept in mind was that
each model object maintains an array of observers (like delegates or
just objects with a declared protocol) to all of which the
corresponding message is sent each time a property of the model object
changes.
Sounds like KVO.
For example,
idMyModelObjectObserver observer;
MyModelObject* myModelObject;
// subscribe observer
[myModelObject addObserver: observer];
// set some prop
[myModelObject setSomeProp:someValue];
@interface MyModelObject
{
NSMutableArray* m_observers;
id m_someProp;
}
@end
@implementation MyModelObject
- (void)addObserver:(idMyModelObjectObserver) observer
{
[m_observers addObject:observer];
}
- (void)setSomeProp:(id)newValue
{
// save new value
m_someProp = newValue;
// notify observers
idMyModelObjectObserver observer = nil;
for (observer in m_observers)
{
[observer somePropChanged];
}
}
@end
Looks like a bad implementation oif KVO.
What is the advantage of reprogramming KVO?
Beside this: Do you want to use core data? What about core data
properties?
Is there something terribly wrong with this approach?
There is nothing wrong in programming a new string class. But why
don't you use NSString?
The dependencies
are encapsulated. In addition, it seems that this approach gives me
more flexibility, say, if newValue is invalid, it can be rejected.
Key value valdidation
Or,
for instance, when the entire MyModelObject gets removed from its
parent model object - in this case there is no property actually
modified, instead, a mutator message is received by the model, but the
observers still need to be notified. Can KVC/KVO monitor the contents
of an array of model objects?
Of course. Look at the array controller.
And so on. Even though KVC/KVO may
handle these cases too, my intuition tells me there can be cases when
the flexibility of KVC/KVO may run short compared to the manual code.
My intuition is, that you don't want to get deeper with KVO und KVC
and are searching for reasons to reject it.
Anyway, even if I assume that KVC/KVO is at least not worse than
manual code, I don't see any real benefit so far. Except that it
allows me to get the scripting support for free (but I'd rather like
the scripting to be separate thing and not get in the way of the model
objects).
Could someone please try to explain me the rationale behind KVC/KVO
once again? :) Thanks
In five minutes?
You want to hold an oberserver list for every property and every
object. This is done by KVO. And ist is done for KVC with Core Data.
And it works with bindings. And it is implemented very good through
isa-swizzling. And And And …
There is nothing wrong in writing a Cocoa II.
But: Why?
Cheers,
Amin Negm-Awad
[EMAIL PROTECTED]
___
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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Thanks Amin for responding. You are correct that there's no need to reinvent the wheel, and that's exactly what I'd like to avoid, that's why I am now re-reading about KVC/KVO and reconsidering it. So, does everybody really always use KVC/KVO for implementing MVC, in all projects? Is this the recommended best practice? BTW does anyone use Core Data? I've watched the video tutorial and it looks like too much magic. I would never guess how to make Core Data work for a drawing application like the Sketch. Is Core Data rather for database+forms apps? Thanks. ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Am Do,21.08.2008 um 16:41 schrieb Oleg Krupnov: Thanks Amin for responding. You are correct that there's no need to reinvent the wheel, and that's exactly what I'd like to avoid, that's why I am now re-reading about KVC/KVO and reconsidering it. So, does everybody really always use KVC/KVO for implementing MVC, in all projects? There are some situation, where glue code is neccessary. Imagine a outline view that has a items lib and some groups, where you can place items from the lib and see them in the outline view by opening the isclosure. Or you have items from different entities there. But even in this case it helps to use KVO on the parts to get synchronized. Is this the recommended best practice? BTW does anyone use Core Data? You're joking? I've watched the video tutorial and it looks like too much magic. I would never guess how to make Core Data work for a drawing application like the Sketch. Is Core Data rather for database+forms apps? 1. Core data is not a database. 2. I think, that you are new to cocoa and a little bit afraid of the magic things. Hey, dive into it, read documentation, try a little bit coding and so on. There is no magic. It's just new land for you. Thanks. Cheers, Amin Negm-Awad [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Oleg, by all means, go ahead with what you started and spend more time learning about KVC/KVO. Yes, this is used in many many projects and I personally would really miss it if it wouldn’t be there. Actually, as you described yourself, if it wouldn’t be there, you’d had to brew something similar yourself. Which I did, coincidental, like 15 years ago under Mac OS 7 or so. Only that Apple can spend a lot more resources than you (I guess) or me (I’m sure) in making this right. And they did. Yes, it has a learning curve. And yes, it is sometimes unfortunate that the inner workings are a black box and can not be looked at with the debugger. Nevertheless, these are minor disadvantages in comparison to the whole thing. Amin already mentioned all the advantages of KVC/KVO as provided by Apple, including the integration with other Cocoa technologies, which a home-brewn solution could never provide. Concerning Core Data: it is equally great - inside its specs. Just take the build-in multi-level undo and redo support. Another great reason to use KVC/KVO, by the way: when Core Data undoes something, KVO is the way to get notified about these changes. Done consistently, this works simply beautiful. And I wouldn’t restrict Core Data to database+forms apps. You can certainly use it for a drawing application. Whether it is the best solution for this kind of application depends - as always - on many details. Hope this helps a little Kai On 21.8.2008, at 16:41, Oleg Krupnov wrote: Thanks Amin for responding. You are correct that there's no need to reinvent the wheel, and that's exactly what I'd like to avoid, that's why I am now re-reading about KVC/KVO and reconsidering it. So, does everybody really always use KVC/KVO for implementing MVC, in all projects? Is this the recommended best practice? BTW does anyone use Core Data? I've watched the video tutorial and it looks like too much magic. I would never guess how to make Core Data work for a drawing application like the Sketch. Is Core Data rather for database+forms apps? Thanks. ___ 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/kai%40granus.net This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Am Do,21.08.2008 um 17:03 schrieb Oleg Krupnov: Amin, It is true that I am new to Cocoa, and although I find the documentation really great and engaging, I have sort of difficulty figuring out what technology is newer/more powerful/built on top of/ other technology. In particular, would you explain me, in just two words, what are the relations between and intended/typical applications of (in the context of implementing the MVC pattern) 1) KVC/KVO KVC is a very old (10.0?) technique to set properties of an entity. In comparison with setters you can choose (change) the property at run- time without changing your code: Entity* instance = …; // imagine this is set [instance setProperty:value]; // you know that You cannot change the name of the property without recompiling. This can be done with KVC: NSString* key; Entity* instance = …; // imagine this is set key= @property; [instance setValue:value forKey:key]; key= @another; [instance setValue:value forKey:key]; Since key is a NSString constructed at run-time, you can change the property at run-time. KVO is newer, I think 10.3 IIRC and something totally different: The core: You get a mesage, if you registered for a property of an instance, that changes. It's quite close to your code. There are differences between automatic and manual KVO, but this is the essence. 2) Bindings Bindings use KVO to get synchronized and KVC for reading/writing data. You can imagine a binding a command to an object, to observe the given key of the given instance. So, hmmm, usually an object starts a KVO, when it becomes bound. Conceptionally: - bind:(NSString*)boundPropertyKey toObject:(id)observed forKeyPath: (NSString*)observedProperty // start KVO [observed addObserver:self forKeyPath:observedProperty]; There are more features through binding options I omitted to clarify. KVO, KVC, and Bindings are placed between the MVC-layers. They typically synchronize a controller to the model and a view to the controller. (Inside a layer you typically do not need KVO, KVC, because the objects inside the same layer know each other. But of course you can use KVO, KVC) 3) Core Data Core data is not neccessarily related to KV*. It is simply a technology for your model to ease the boring work of defining entites, writing accessors, supporting serialization…. But core data is KVC- and KVO-compliant, that means, that you can set/ read properties to/from an core data entity and you're able to observe the properties. Short: You *can* use KV technologies with core data. Using core data or not and using KV* or not is orthogonal. 4) Anything else I may have overlooked? If Core Data is really that cool, why don't one always use it instead of KVC/KVO or maybe Bindings? See above. You do not use core data or KV*, but core data and KV* BTW I didn't say I thought Core Data was a database, I said it may be intended rather for database apps. Okay :-) The usage is quite simple (if I'm allowed to simplify that) Without core data In your model you have classes for entities, let's say Person, Department, Company, Account … These classes are typically subclsses of NSObject. So you have to define the ivars, write accessors (okay, Objctive-C 2 …), maybe support undoing, support serialization with NSCoding … With core data In many cases you do not need any subclass, but simply use NSManagedObject. The definition of the model can be done in the modeller very easy. Undoing, Coding and so on will work. Cheers Amin Negm-Awad [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
I have some quibbles... On Aug 21, 2008, at 12:54 PM, Erik Buck wrote: So, in summary, the whole point of KVC is to standardize the way an object’s properties are accessed regardless of how they are stored. Well, the real point, to my mind, is to increase the dynamism of property access. It's to allow properties to be accessed using data to select the property rather than code. Data that is determined at runtime or design time (IB). KVC also provides support (hooks) for change management so that any change to a property can have application defined side effects like registering an undo event or validating the change. Hooks other than the accessors it might invoke? I'm not aware of that. KVO Key Value Observing takes advantage of the change management hooks provided by Key Value Coding in order to notify other interested objects whenever an observed property changes. Again, I don't think KVO takes advantage of existing hooks. It adds those hooks by generating subclasses dynamically and isa-swizzling. Unless and until you add a KVO observer to an object, it doesn't have any hooks. KVO is also the basis of “Bindings”. I would go so far as to say “Bindings” are just a way to specify which objects observe which properties in which other objects using Interface Builder instead of writing code to register all those notification observers. Bindings do more than merely set up KVO observations. The classes which support bindings also determine what to do when changes are observed. Although KVO is “built upon KVC”, KVO really only needs change notifications. So, if you provide the change notifications, KVO will work even if you don’t really use KVC. I don't think that's true. KVO relies on KVC. How else can a KVO change notification include the old or new value? KVO will perform a KVC query for will/didChange... messages (including the implicit, automatic invocations of will/didChange... performed in the hooks it installs). Cheers, KEn___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Remember that NeXT and Apple didn't just invent KVC, KVO, and Bindings out of thin air for no better reason than they were enamored of the idea. There was a substantial history of NeXTStep/OpenStep/Cocoa programs written. The developers at NeXT and then Apple recognized that there was a large body of repeated design elements and implementations for some very common tasks. Gradually they extracted these commonalities, generalized them, and implemented them in a way intended to allow the elimination of all (or most) of those previous custom implementations. In other words, there's a reason that the design you came up with on your own is so similar to what KVO actually does. It's because Apple has seen such designs before many, many times -- I'm sure they wrote their own implementations many times for many programs and frameworks -- and they eventually created KVO just so you (and they, and all of us) would never have to implement that same thing over again. The same with Bindings. Reading the Bindings guide actually describes the thought process behind this feature of the framework. Many, many projects were filled with repetitive controller glue code for updating views from models and vice versa. Apple figured out a way to write a feature into the frameworks to eliminate a huge amount of that repetitive glue code. So, while there's no rule that you have to use KVC, KVO, or Bindings in your own code, chances are good that you'll just end up reinventing them badly. If it weren't highly probable that you'd do that, then KVC, KVO, and Bindings wouldn't exist. Cheers, Ken ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote: I have some quibbles... On Aug 21, 2008, at 12:54 PM, Erik Buck wrote: So, in summary, the whole point of KVC is to standardize the way an object’s properties are accessed regardless of how they are stored. Well, the real point, to my mind, is to increase the dynamism of property access. It's to allow properties to be accessed using data to select the property rather than code. Data that is determined at runtime or design time (IB). I agree. Cocoa Design Patterns includes an entire chapter about the Associative Storage design pattern, and the whole point of the pattern is to provide dynamism that allows determination at runtime. I perhaps over simplified out of a desire to avoid pasting the whole Associative Storge pattern into the essay. KVC also provides support (hooks) for change management so that any change to a property can have application defined side effects like registering an undo event or validating the change. Hooks other than the accessors it might invoke? I'm not aware of that. In order to make your classes KVC compliant, you must either write the appropriate accessors or override the valueForKey: and related methods. The hooks in fact are the accessor methods or the valueForKey: type methods. KVO Key Value Observing takes advantage of the change management hooks provided by Key Value Coding in order to notify other interested objects whenever an observed property changes. Again, I don't think KVO takes advantage of existing hooks. It adds those hooks by generating subclasses dynamically and isa-swizzling. Unless and until you add a KVO observer to an object, it doesn't have any hooks. The hooks are just the accessor methods or KVC compliance methods. They exist for every KVC compliant class. However, you can use KVO with a class that is not totally KVC compliant if you call the appropriate willChangeValueForKey: and didChangeValueForKey: methods. Obviously it works best with KVC compliant classes. OK - I'll concede that KVO should only be used with KVC compliant classes. The last time I described all this in email, I was shot down for even bringing up the isa-swizzling becaust that's an obscure implementation detail... KVO is also the basis of “Bindings”. I would go so far as to say “Bindings” are just a way to specify which objects observe which properties in which other objects using Interface Builder instead of writing code to register all those notification observers. Bindings do more than merely set up KVO observations. The classes which support bindings also determine what to do when changes are observed. That's a detail. The essay was intentionally kept to the main points. I wanted to focus on the notification aspect because that's whate the original poster was trying to re-implement. Although KVO is “built upon KVC”, KVO really only needs change notifications. So, if you provide the change notifications, KVO will work even if you don’t really use KVC. I don't think that's true. KVO relies on KVC. How else can a KVO change notification include the old or new value? KVO will perform a KVC query for will/didChange... messages (including the implicit, automatic invocations of will/didChange... performed in the hooks it installs). OK OK - I'll concede that KVO should only be used with KVC compliant classes. ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On Aug 21, 2008, at 7:09 PM, Erik Buck wrote: On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote: On Aug 21, 2008, at 12:54 PM, Erik Buck wrote: KVC also provides support (hooks) for change management so that any change to a property can have application defined side effects like registering an undo event or validating the change. Hooks other than the accessors it might invoke? I'm not aware of that. In order to make your classes KVC compliant, you must either write the appropriate accessors or override the valueForKey: and related methods. The hooks in fact are the accessor methods or the valueForKey: type methods. Well, OK. In that sense, every method is a hook, insofar as a subclass could override it to do something before/after/instead of what the method would normally do. When I think of hooks, I usually think of methods that exist solely to provide clients an opportunity to do something at certain points. The framework calls them not for its own purposes but just to give clients an opportunity to do something else. For example, the real meat of -[NSWindowController window] is in its -loadWindow method. However, for the convenience of its clients (and solely for that reason), it also invokes -windowWillLoad and -windowDidLoad (and the associated document's -windowControllerWillLoadNib: and - windowControllerDidLoadNib:, if present). And, of course, delegate methods are a prime example of hooks. I suppose that's a pedantic distinction, though. Again, I don't think KVO takes advantage of existing hooks. It adds those hooks by generating subclasses dynamically and isa- swizzling. Unless and until you add a KVO observer to an object, it doesn't have any hooks. The hooks are just the accessor methods or KVC compliance methods. They exist for every KVC compliant class. Technically, a class may be KVC-compliant even without the KVC accessors. If the class has the appropriately-named instance variable, it qualifies (although I'm sure we agree that programmers _should_ provide the accessors, especially for proper memory management). I guess, in that case, you might consider the -valueForKey: and - setValue:forKey: methods themselves to be the hooks. *shrug* Cheers, Ken ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On 22 Aug 2008, at 1:03 am, Oleg Krupnov wrote: 4) Anything else I may have overlooked? I've read through this thread and it's very interesting. But one thing that has been overlooked - common or garden notifications. If all you want is to pick up a change in an object a notification is a simple way to do it without writing your own messaging system. It's less powerful than KVO but simpler to understand and much less fussy about managing its connections than KVO. Think of it as a half-way house between doing it all yourself and using KVO, which might seem to be too much magic for some. Check out NSNotificationCenter. cheers, Graham ___ 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 [EMAIL PROTECTED]
Design Question: Pro Cons of KVC/KVO
Ken, Thanks for your explanation of the development of KVC, KVO, and Bindings. As a geezer who spent most of his career coding in assembler on IBM mainframes beginning in the late 60's, it is still sometimes difficult not having total control over my code. KVC, KVO, and Bindings is one of the areas I really avoided but your comments have reminded me that there is a reason for it. Bill ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
So, does everybody really always use KVC/KVO for implementing MVC, in all projects? Is this the recommended best practice? From code written after 10.2, yeah, pretty much. Coupled with the tools support in Interface Builder and the AppKit support with Cocoa Bindings, it's really not worth the effort of reimplementing KVC or KVO in general. BTW does anyone use Core Data? I've watched the video tutorial and it looks like too much magic. I would never guess how to make Core Data work for a drawing application like the Sketch Core Data is an ORM framework for Cocoa whose purpose is to fill the M part of MVC patterns. AppKit and Cocoa Bindings fill V and C respectively. Although it does not support client server databases, there are similar products in that enterprise space such as EOF, Hibernate, Cayenne, JDO, .NET Entity Framework, and the ActiveRecord pieces of Ruby on Rails. Just as all those products provide many more features than ODBC/JDBC (e.g. a database), so too does Core Data provide a lot more than raw data persistence. While I like to imagine that there is a pinch of magic in Core Data for specific technical problems, the concepts and features are not magical. The theory behind these systems dates back to the mid 70s, and they became commercially popularized in the 90s. You can ask wikipedia for more details about ORM and ERM. Core Data does not force you to use it with KVC or KVO, but since it leverages many of the same ideas, understanding KVC KVO first would be wise. Is Core Data rather for database+forms apps? No, Core Data is for Model objects within Cocoa applications. You can use it just as easily with a Foundation command line tool if you don't need Views or Controllers. - Ben ___ 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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On Thu, Aug 21, 2008 at 10:27 PM, Graham Cox [EMAIL PROTECTED] wrote:
But one thing that has been overlooked - common or garden notifications. If
all you want is to pick up a change in an object a notification is a simple
way to do it without writing your own messaging system. It's less powerful
than KVO but simpler to understand and much less fussy about managing its
connections than KVO. Think of it as a half-way house between doing it all
yourself and using KVO, which might seem to be too much magic for some.
I don't think using notifications for communication between specific
objects is the best idea. I tend to think of notifications for
broadcasting state changes that any other object may be interested in.
For example, say I have a window with a toolbar and an NSSplitView.
It wouldn't make sense to use the delegation pattern between my split
view and my toolbar. So that leaves me with two options,
architecturally:
1) Create a C#-style event handler list. In C# (and other .NET
languages, but C#'s syntax is easiest), objects declare that they have
events. So a SplitView class in C# might have an event called Resize:
delegate void ResizeDelegate(object sender, EventArgs e)
class SplitView
{
public event ResizeDelegate Resize;
}
Then, somewhere I would wire my toolbar up to that event:
class Toolbar
{
public Toolbar()
{
// Make the SplitView notify us if it resizes
theSplitView.Resize += new ResizeDelegate(this.toolbar_Resized);
}
private toolbar_Resized(object sender, EventArgs e)
{
// Typical example: change the text on a show/hide side pane button
}
}
This approach is very in keeping with C#'s static typing; the events
an object can raise are well-defined members of the class. The
downside, though, is that somehow your client objects need to know
about all the objects that they want to attach themselves to. Your
object graph gets very, very dense if you have more than a few of
these sorts of events.
2) Broadcast notifications to anyone who may be interested.
@implementation SplitView
{
-(void) setSize:(NSSize)newSize
{
[[[NSNotificationCenter] defaultCenter]
postNotificationName:SplitViewResized object:self];
}
}
@end
Now my client objects can specifically listen for this message coming
from this SplitView, or they can listen for all messages, or just this
message from any SplitView.
@implementation ToolBar
{
-(id) init
{
[[[NSNotificationCenter] defaultCenter] addObserver:self
selector:@selector(splitViewResized:) object:mySplitView];
}
}
Much more flexible, but at the cost of knowing what messages the split
view might throw, and it loses the static typechecking that the C#
delegate approach affords; the C# event is typed as only taking
methods which return void and accept an object and an EventArgs, while
the Cocoa method will fail at runtime if ToolBar doesn't implement
-splitViewResized:.
The real power of notifications comes when you have, say, a hundred of
something. You want some UI element to know when any of your hundred
things enters state X (a collision, for example). With .NET events,
you have to register this object with each of your target objects. In
Cocoa, your objects just scream out and the client hears them.
--Kyle Sluder
___
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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On Fri, Aug 22, 2008 at 3:59 PM, Kyle Sluder
[EMAIL PROTECTED] wrote:
@implementation ToolBar
{
-(id) init
{
[[[NSNotificationCenter] defaultCenter] addObserver:self
selector:@selector(splitViewResized:) object:mySplitView];
}
-(void)dealloc
{
[[NSNotificationCenter] defaultCenter] removeObserver:self];
[super dealloc];
}
@end
I've generally only used notifications for events that can't be
handled with KVO---ie. those that aren't associated with a property
change; and I've noticed that this is generally the trend in Cocoa
frameworks as well. Why use NSNotifications when there's already
perfectly good notification mechanism?
That said, notifications also give you a lot more flexibility about
when observers will be called, and coalescence of multiple
notifications.
Phil
___
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 [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On 22 Aug 2008, at 2:22 pm, Phil wrote: Why use NSNotifications when there's already perfectly good notification mechanism? Indeed, but notifications have been around a lot longer than KVO, so there are still plenty of places in Cocoa that notifications are used for legacy reasons. Also, as others have mentioned, they are better when you have more than one object that you might have an interested in. With KVO you have to subscribe to each individually, with notifications you can subscribe to the same notification from any object that might send it. Horses for courses, as usual. My point was that notifications are a messaging mechanism; KVO or rolling your own aren't the only games in town. So notifications should be considered when thinking about messaging. If subsequently rejected for a given design, so be it. cheers, Graham ___ 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 [EMAIL PROTECTED]
Re: Design question, which controller class to use
On Mon, Jul 21, 2008 at 4:05 AM, James W. Walker [EMAIL PROTECTED] wrote: I have these windows, each of which has a table displaying data from an array of dictionaries. The data is never stored on disk, so I don't think of these windows as documents. In addition to what Jens said: If the user can create new ones and they are largely unrelated to one another, you may yet find it easier to use most of the NSDocument machinery but disable the persistence stuff. If there are a fixed number and/or they are interrelated, it may be easier to use NSWindowController directly. Hamish ___ 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 [EMAIL PROTECTED]
Re: Design question, which controller class to use
On Jul 20, 2008, at 10:24 PM, Jens Alfke wrote: On 20 Jul '08, at 8:05 PM, James W. Walker wrote: Since there is a window (which has a title that depends on the data) I thought I should use a subclass of NSWindowController. On the other hand, there is an array being displayed in a table, and I gather that's easier to set up using bindings if I use an NSArrayController. Any suggestions or references? Those are two very different types of controllers, and you should probably use both. Just to add to that: Apple's terminology for these different types are coordinating controller and mediating controller. You should do a full-text documentation search for those terms and read the discussion you find there. It will help you understand the concepts. Cheers, Ken ___ 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 [EMAIL PROTECTED]
Design question, which controller class to use
I have these windows, each of which has a table displaying data from an array of dictionaries. The data is never stored on disk, so I don't think of these windows as documents. Since there is a window (which has a title that depends on the data) I thought I should use a subclass of NSWindowController. On the other hand, there is an array being displayed in a table, and I gather that's easier to set up using bindings if I use an NSArrayController. Any suggestions or references? ___ 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 [EMAIL PROTECTED]
Re: Design question, which controller class to use
On 20 Jul '08, at 8:05 PM, James W. Walker wrote: Since there is a window (which has a title that depends on the data) I thought I should use a subclass of NSWindowController. On the other hand, there is an array being displayed in a table, and I gather that's easier to set up using bindings if I use an NSArrayController. Any suggestions or references? Those are two very different types of controllers, and you should probably use both. An NSWindowController helps manage a window. It's a good idea to use these for all non-document windows. This will be the file's owner in your nib. An NSArrayController manages an NSArray and lets you bind GUI controls to it. So you'd probably put one of those in your nib as well, to help run your table. —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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Design question
Hi all, As a developer entering the cocoa world for the first time one of the things I am finding difficult is how to start structuring an application, I mean what classes should I create to make an OK application design. I have a simple application I am working on at the moment, and am hoping someone can give me some pointers on the classes I should write. The application will be using the Quicklite framework to connect to SQLite databases and display a selection list of all tables in the database, with a table view to show the data from the selected table. A first attempt at designing the application has come up with the following, - I will need a class to open and maintain the connection to the database. I was thinking of using an Application Delegate class to do this and then expose the connection via a property. - I will need a view controller class for the table list UI object. This controller class will goto the Application delegate for the database connection and ask it a list of tables in the database. It will also maintain the current selected table. Any changes to the selection will trigger a call to the table view controller to make an update. - I will need a view controller class for the table view UI object. This controller class will goto the application delegate for the database connection and ask for table/row information as needed to display in the table. The current selected table is read from the table list controller object. - I will need to provide outlets in the controller classes so interface builder can bind them all together. Does anyone have any comments on my design so far? Thanks Phillip Hall ___ 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 [EMAIL PROTECTED]
Re: Design question
I'd agree with what I.S. said, make sure you read up on and run through some tutorials for coding a table and its data source by hand. Aaron Hillegass does a great job of this in Cocoa Programming for Mac OS X. As a Cocoa newbie this is a great book to hit the ground running. It assumes prior programming knowledge, but starts at the basics (like table data sources) and goes right up through to the advanced. I'm not the first to recommend his book on this list and I know I won't be the last. Regards, Michael On Jul 14, 2008, at 9:35 PM, I. Savant wrote: Does anyone have any comments on my design so far? Overcomplicated. :-) If I were writing a quick utility to do as you're looking to do, I'd probably implement it all in a single application controller. There's no real design advantage in something with so few requirements and simple is always best. If your project becomes more complicated (the app controller is too big to manage mentally / textually, or some parts of your controller layer need to be reusable), you can decide what to parcel out into more logical divisions. For now, though, there's nothing wrong with using a single controller and nothing to gain from using multiple ones. Also, the general advice (with which I concur whole-heartedly) is to steer clear of Cocoa Bindings until you've masted the Cocoa Basics. That is, for your tables, try the NSTableDataSource protocol to see the nuts and bolts of tables before worrying about the more complicated Bindings machinery. Good luck and happy coding! -- I.S. ___ 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/michaelfey%40fruitstandsoftware.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Re: Design Question: Where to observe using KVO?
Ken Thomases wrote:
How about a dictionary whose keys are NSValues representing the
objects? For each object, the value from the dictionary would be an
NSMutableArray whose elements are the key paths being observed on that
object.
// ...
NSValue* objectKey = [NSValue valueWithNonretainedObject:object];
NSMutableArray* keyPaths = [observers objectForKey:objectKey];
if (!keyPaths)
{
keyPaths = [NSMutableArray array];
[observers setObject:keyPaths forKey:objectKey];
}
[keyPaths addObject:keyPath];
Hi Ken
Do you think that observing lots of objects with lots
of keypaths is a good idea anyway?
Maybe I'm considering my first approch again, using only key-value
coding inside the view and move the observing somewhere else ...
What I like about your idea is the use of
[NSValue valueWithNonretainedObject:object];
I didn't know that. I'm quite new to coocoa, but not to programming.
Since the number of keypaths for each object is constant, I might
decide using a custom bitmap object as the value part in the
dictionary. That bitmap would indicate which keypath is being observed.
Thanks a lot.
Patrick
___
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 [EMAIL PROTECTED]
Re: Design Question: Where to observe using KVO?
On Jul 11, 2008, at 2:45 AM, Patrick Mau wrote: Do you think that observing lots of objects with lots of keypaths is a good idea anyway? Honestly, I've forgotten the original design issues you're considering. If you need to observe lots of objects and key paths to achieve your purposes, then do that. Of course, it can't hurt to consider some alternatives, like Notifications. See the Cocoa Fundamentals Guide for some other possibilities. One technique with KVO to reduce the number of keys that you need to observe on an object is to create a new property which acts as a single thing to observe which stands for a constellation of other properties. Often, if one object is observing many properties of another object, there is one abstract concept that it's really interested in. It's observing the many properties because it has too- intimate knowledge of the inner workings of the other object -- the classes are too closely coupled. Instead of the observed object presenting an abstract concept as a whole thing, it's exposing the implementation details from which that whole is composed. That forces the observer to pay attention to all of those details. In such cases, you should use +keyPathsForValuesAffectingValueForKey: (Leopard and later) or +setKeys:triggerChangeNotificationsForDependentKey: (if you need to deploy to earlier OS versions) to teach KVO which detail properties comprise the whole-concept property, so change notifications in one cause change notifications of the other. Since the number of keypaths for each object is constant, I might decide using a custom bitmap object as the value part in the dictionary. That bitmap would indicate which keypath is being observed. Sounds like premature optimization to me. *shrug* Cheers, Ken ___ 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 [EMAIL PROTECTED]
Re: Design Question: Where to observe using KVO?
On Jul 10, 2008, at 4:55 PM, Patrick Mau wrote:
I'd like to show you one ugly detail. I put all observed objects,
including their keyPath in a local NSDictionary, because I have to
remove the observers on deletion of a table row. The 'observeObject'
looks like that:
- (void)observeObject:(id)object withKeyPath:(NSString *)keyPath {
NSLog(@start observing %p with keypath %@, object, keyPath);
[object addObserver:self forKeyPath:keyPath
options:NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld
context:nil];
[observers setValue:object forKeyPath:[NSString
stringWithFormat:@%p.%@, object, keyPath]];
}
In my opinion, this is as ugly as it can possibly get.
I'm using the address of the observed object and append the keypath to
create a pseudo key for each observed instance.
I don't like that at all, but how would I be able to remove all
observers when I have to clean them up later?
Is there a better approach instead of observing every property of all
array entries?
How about a dictionary whose keys are NSValues representing the
objects? For each object, the value from the dictionary would be an
NSMutableArray whose elements are the key paths being observed on that
object.
// ...
NSValue* objectKey = [NSValue valueWithNonretainedObject:object];
NSMutableArray* keyPaths = [observers objectForKey:objectKey];
if (!keyPaths)
{
keyPaths = [NSMutableArray array];
[observers setObject:keyPaths forKey:objectKey];
}
[keyPaths addObject:keyPath];
Cheers,
Ken
___
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 [EMAIL PROTECTED]
Design Question: Where to observe using KVO?
Hallo everyone I would appreciate if someone wants to comment on my conceptual design question: I have developed a custom NSView displaying a pie chart. The data is an NSMutableArray containing NSMutableDictionary instances for the pie segments (a standard NSArrayController instance). Each segment consists of a label, color, tooltip and value. My first approach was to keep the data array in the application controller and implement NSView selectors like: - (int)addSegmentWithValue:(NSValue *)value withLabel:(NSString *)label; - (void)removeSegmentAtIndex:(int)index; - (void)setLabel:(NSString *)label forSegmentAtIndex:(int)index; - (void)setTooltop:(NSString *)toolTip forSegmentAtIndex:(int)index; - (void)setValue:(NSValue *)value forSegmentAtIndex:(int)index; ... you get the idea I would observe the data array in the controller and send messages like the above to the view instance. Pros: - The logic is kept in the controller - The view's data model is hidden in the implementation. - Updates to the view are completely independent (flexible) Cons: - Segment data is duplicated in the view and the model/controller part - I have to ensure the view is updated properly using setNeedsDisplay: - Lots of messages have to be sent to the view instance - A lot of glue code implemented in the controller My second approach was to let the pie chart view observe the whole array. It would also add itself as an observer on addition or removal of array elements. There's only one line of code in the controller registering the view. Pros: - Fewer lines of code, the view observes the array - Messages are sent automatically to the view using KVO - The view's data is always consistent Cons: - The view's data model is exposed to the outside world - changes of the view's functionality would be harder to implement - Lots of messages like '[self setNeedsDisplay:YES]' Flexibility: - How would I prevent updates ? (lock segments, prevent removal, etc.) - How would I connect segments (segment 'A' and 'B' always cover 33%)? - How would I use animation while data might change under me? (stop observing? that would be inconsistent) This post is getting too long already, sorry. Where would you observe changes to data? On the one hand the view needs consistent data, but in my opinion the application's data should be separate from the data hosting the appearance of the view. Thanks a lot for reading Patrick PS: I have been silently reading this list for a few weeks now, I really enjoy it! ___ 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 [EMAIL PROTECTED]
Re: Design Question: Where to observe using KVO?
Where would you observe changes to data? I think you should worry about one thing at a time (ie, leave the animation part for another day and concentrate on your bindings machinery first). Check out this page: http://homepage.mac.com/mmalc/CocoaExamples/controllers.html Great examples of Bindings in action. You'll be interested in the Graphics Bindings and the Manual Bindings examples as they cover (among other things) the kind of approach you're likely to want. Hooking in the animation (because as you said, things can change) would be done taking the examples' approaches into account. Specifically, you'd handle the animation as you would without bindings ... only it's triggered within your observation code. You have a chance to examine the 'old' and the 'new' there and respond in kind. -- I.S. ___ 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 [EMAIL PROTECTED]
Re: Design Question: Where to observe using KVO?
Check out this page: http://homepage.mac.com/mmalc/CocoaExamples/controllers.html I should also mention that you should approach these examples like this: 1 - Read the Cocoa Bindings documentation (including all the Key Value Coding / Key Value Observing related documentation). 2 - Examine the examples given above. 3 - Go back over the documentation!!! Seeing a working example makes a second perusal of the docs much more fruitful. -- I.S. ___ 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 [EMAIL PROTECTED]
Re: Design Question: Where to observe using KVO?
I. Savant wrote:
Check out this page:
http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
I should also mention that you should approach these examples like this:
1 - Read the Cocoa Bindings documentation (including all the Key Value
Coding / Key Value Observing related documentation).
2 - Examine the examples given above.
3 - Go back over the documentation!!! Seeing a working example makes a
second perusal of the docs much more fruitful.
Thanks a lot for your remarks, I really appreciate it. My basic
implementation already works!
I have built a master-detail window, using an NSTable view for label
and amount. My PieChartView is observing the array like this:
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context
{
NSLog(@observeValueForKeyPath:%@ ofObject:%p %@, keyPath, object,
change);
int i;
NSArray *changedObjects;
int changeType = [[change valueForKey:NSKeyValueChangeKindKey] intValue];
switch (changeType) {
case NSKeyValueChangeInsertion:
changedObjects = [change valueForKey:NSKeyValueChangeNewKey];
for (i = 0; i [changedObjects count]; i++) {
[self observeObject:[changedObjects objectAtIndex:i]
withKeyPath:@label];
[self observeObject:[changedObjects objectAtIndex:i]
withKeyPath:@amount];
}
break;
This is an excerpt of the code executed whenever a new row is added to
the NSTableView. I observe the new NSDictionary provided by
NSArrayController. Deleting multiple rows also works.
I'd like to show you one ugly detail. I put all observed objects,
including their keyPath in a local NSDictionary, because I have to
remove the observers on deletion of a table row. The 'observeObject'
looks like that:
- (void)observeObject:(id)object withKeyPath:(NSString *)keyPath {
NSLog(@start observing %p with keypath %@, object, keyPath);
[object addObserver:self forKeyPath:keyPath
options:NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld
context:nil];
[observers setValue:object forKeyPath:[NSString
stringWithFormat:@%p.%@, object, keyPath]];
}
In my opinion, this is as ugly as it can possibly get.
I'm using the address of the observed object and append the keypath to
create a pseudo key for each observed instance.
I don't like that at all, but how would I be able to remove all
observers when I have to clean them up later?
Is there a better approach instead of observing every property of all
array entries?
Patrick
___
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 [EMAIL PROTECTED]
Re: MVC Design Question
Take a look at this work by Robbie Hanson: http://deusty.blogspot.com/2008/02/towards-open-source-xmpp-framework- for.html http://code.google.com/p/xmppframework/ I can't vouch for the style of its internal design, but there is a lot there to leverage. I'm building my own native Cocoa XMPP protocol stack, so feel free to contact me directly. From: vance [EMAIL PROTECTED] Subject: MVC Design Question If you would design an IM client using MVC, where would the connection object be? ___ 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 [EMAIL PROTECTED]
