I have a tree data structure which I would like to put into an NSBrowser. I have found complicated methods that involve App Delegates, but I would just like to insert the rows as I come across them.
An NSBrowser is a view. A view generally doesn't hold onto a whole complex tree of model objects—that's a controller's job. That's why you appoint your custom controller (and owner of your model objects) as the delegate of the browser: You own your entire model, and the view gets parts of it from you as it needs them.
Related
im a osx-dev noob that is trying to build an application with three table views that will show the content of a core data store entity. But each table view is filtered on the attribute "status" of the entity.
the problem occurs when i also want to show the selected entity in textfields. I'm using three different array controllers with different fetch predicates. But in a textfield i can only bind the value to one array controller.
should i ditch the bindings and do it all programaticly or is there a simple solution to this? :)
here is an screenshot so you can grasp my app description.
Keep bindings to populate the text fields if it satisfies what you want to do with this GUI. I'd add an NSObjectController to control the one entity those fields represent. If you want the user's changes to those fields persisted, bindings are still awesome.
But I think with three tables that might control what's displayed in the text fields, you're going to need to have some sort of non-binding glue code that determines which of the tables wins. You can probably do everything you want by implementing some of the NSTableViewDelegate protocol.
If the text fields should display the last entity that the user clicked in any of the tables, simply have each table call the same tableViewSelectionDidChange delegate function. All three tables could have the same delegate. You can then call setContent on the NSObjectController from that function.
You could also use similar glue code to prevent more than one selection in any of the three tables, by having the same delegate function deselect everything in the other tables either through the view or the controller. But that's up to you and needs consideration of whether you want multiple selection, etc.
If I am using an instance of NSArray to populate a pop-up button, where in terms of MVC does that NSArray need to be initialised? I'm guessing it would fall under Model, however if that's the case, how do I initialise the array? Do I start a new implementation file to contain the array? (Obviously don't want to use my app delegate file as that would fall under Controller, not Model.)
The "model" part of MVC is the data that the app stores, presents, and/or allows the user to manipulate. It would largely be the same whether your app was running on a Mac, an iPhone or whatever. The "view" is the UI. That is the things the user actually sees on screen. The controller is the part that goes in between these two. It's responsible for implementing the specific behavioral logic for the app as well as "gluing" the view layer to the model layer.
So, with that said, the array of items to be displayed in a popup button may or may not be part of the model. It entirely depends on the specific UI you're implementing. If the selection is between a number of objects represented in the model, the array's contents would indeed be part of the model, but it still might be that the controller pulls the items out of the model in another form and turns them into an NSArray. It might also be a way to select between e.g. a fixed list of actions to be performed, in which case it's more properly part of the controller layer itself.
In other words, there's no one answer to your question. But, the likelihood is that the controller will at least provide the array in question to the UI, and may also be entirely responsible for its content. It all depends on exactly what you're trying to accomplish.
The initialization would happen within the model object, but that initialization would likely be called from a view controller (I wish these were just called controllers--there's no ModelController class.) Possibly in viewDidLoad but really wherever the best fit for your use case would require.
The model object should initialised by the controller object, usually in the viewDidLoad method. If a model object is owned by another model object (for example, if your custom model object has an NSArray instance variable, then your custom object is the parent and the NSArray is the child), then that child model object should be initialised in the initialised method of the parent model object.
I suppose your NSArray is a model object on its own, so it should be initialised in the viewDidLoad method of the controller object.
This is just one answer and not necessarily how everyone develop applications in objective C.
If I have an app with a small data model or with models scoped to their views, I will put the models on the AppDelegate or in the viewControllers themselves, if they are limited in scope to that view.
They will be initialized closest to where it makes sense in the app for that data.
Sometimes you will see a "FAT" viewController which represents a home screen controller or main screen controller and folks will pile the models on that class. Its very common.
But if I have an application with a large data model - lots of models that have lifetimes not scoped to the life of a view - then I will create a class in my application called *myAppNameHere*AppModel, and I will centralize the storage of application models, and use service classes as necessary to request data to populate/update models.
This is just one approach. And great question!
I have some hierarchical data model that I'd like to present in an NSOutlineView. I'm binding a tree controller to the outline view to provide data and to handle selection and binding to other views.
However, I only want to show only part of the data in my model to the outline view. (Each object in my hierarchy has an array of child objects, but I'd only like some of these child objects to appear as child nodes of the node in the tree.) I wish I could just attach a filter predicate to the tree controller, but it seems that NSOutlineView doesn't support filter predicates.
I think that this design requires an NSOutlineViewDataSource to filter my data model, and an NSTreeController bound to the data source and the outline view. However, none of the binding outlets in the tree controller (Content Array, Content Object, Content Set, etc.) seems appropriate for binding a data source.
Any ideas? Thanks in advance...
You can try feeding the data to your array of child objects through an array controller.
Here's how I'd do it. Override the accessor method in your represented object and return a filtered array from your array controller.
In general, NS[Outline|Table]ViewDataSource and Cocoa Bindings is an "either/or" choice. Mixing the approaches, while perhaps not strictly impossible, will likely lead to unpredictable results.
You mention binding a filter predicate to the Outline View itself and not to specific nodes, so I surmise that one filter predicate for all nodes might be "good enough." If that's the case, then one solution to this would be to expose a second children-vending property on your model, maybe filteredChildren, and tell the NSOutlineView to use that to access children instead of the your default/complete children-vending property. If you need functionality like drag reordering, this approach might prove to be non-trivial, but it should be easy to explore this approach regardless.
If you need a different filter for each node, or if the filter changes dynamically, this task would likely have crossed over into being a case that was a good candidate for implementing NSOutlineViewDataSource (and a poor candidate for using Cocoa Bindings.)
I'm developing a Mac Application. The application has a common source view on the left and a detail view on the right which is the main part of the whole window.
It's like a Master-Detail relationship, but each element in the source view require another detail view. In fact, I have designed a specific NSViewController for each element in the source view.
If I'm switching between these NSViewControllers, that means If I select another element in the source view, I remove the current view and add the view of the newly selected NSViewController. Everytime I change the NSViewController, its state will be lost. When the user comes back to that NSViewController, he has to start over.
My question now is: How can I save the state of the NSViewController, so that I can switch between these without losing its states and can continue where I have left?
Two considerations about your problem:
Keep model data in model classes. This means that you can always recreate a view controller and set its represented object provided the model classes have kept the changes made via the view controller. When you need to instantiate a view controller, set its represented object to (a representation of) a model class.
When removing a view from its superview, you do not necessarily need to release its corresponding view controller. Instead, you can keep strong references to all view controllers in your window controller/application delegate, so no state is actually lost.
Use NSArchiver. Implement archiving/unarchiving in your dealloc/init methods and store each view controller's state in a file named after the class (if you have one item per view controller policy). Otherwise think of some simple naming convention and use it.
Result should be an settings panel with an OutlineView and "add item", "add group" and "delete" buttons. The buttons add entries to an NSOutlineView. The data is stored in a NSMutableDictionary (or whatever is suitable). Sorting/DragDrop enabled for the OutlineView.
What is the best or most comfortable way for this (and write less code)?
Modifying NSMutableDictionary, NSOutlineView refreshes from NSMutableDictionary?
Modifying NSOutlineView, Result is stored in NSMutableDictionary?
... NSTreeController?
... CoreData?
What's best practice for that?
Thanks in advance!
This is a pretty broad question. You should always store your model data in a model object of some kind, be that a Core Data entity, an NSMutableDictionary or a custom object of your own creation. You should definitely NOT be storing the data in an NSTreeController or NSOutlineView instance, these are not model objects.
If you're using Core Data for the rest of your app and you need to persist the data that is manipulated by the outline view then this is a good choice, but it might be overkill if you have only simple requirements.
To control what is displayed in the outline view you can either use NSTreeController or your own controller object that responds to the NSOutlineView datasource and delegate protocols. In practice you might use both, as some things such as whether or not an item is a group item can only be controlled by the NSOutlineView delegate methods.
In my personal experience I've found that NSTreeController can be very difficult to deal with for anything beyond very simple tasks and I now longer use it, I find it's much simpler to just use the datasource methods in my own controller.
As far as modifying the contents of the outline view, you should always modify the model via a controller, you should never update the view directly. You would implement methods such as -add: in your controller or use the -add: method of NSTreeController if you're using it.
Your view's controller should then detect the change in the model and ask the view to update. The view controller and model controller can be the same object but they don't have to be. Key-Value Observing is a useful technology that can inform your controller of a change in the model.
Here's some sample code from Apple that you might find useful:
http://developer.apple.com/mac/library/samplecode/SourceView/
http://developer.apple.com/Mac/library/samplecode/AbstractTree/