I'm not really sure how to start debugging this issue.
I've got an NSCollectionView, whose NSCollectionViewItem prototype view itself contains an NSCollectionView (as well as an NSArrayController, to provide content to this 2nd-level collection view). Both levels of collection view work fine when the top-level view is in the main nib.
However, when I copy/paste the view (and reconnect all the appropriate bindings) to a new nib, which I load with loadNibNamed:owner:, the 2nd-level view--but not the top-level one--appears blank.
Upon some investigation, I discovered that myArrayController.arrangedObjects.#count is indeed 0. HOWEVER, the NSArray the controller is bound to (File's Owner's representedObject.quizzes), when asked for .#count, returns 2.
quizzes should indeed return 2, for I've done [testCategoryA setQuizzes:[NSArray arrayWithObjects:testQuizA1,testQuizA2,nil]];. I've tested setting the quizzes before the nibs are loaded and after. The situation is the same in both cases.
So, in conclusion, I've got 2 levels of collection views, with 2 levels of array controllers. The top level always works. But the 2nd level breaks whenever the top level isn't in the main nib file. And it seems to me that the part about the 2nd level that breaks is the binding of the array controller.
I don't even know how to start debugging in this tangled mess of nibs. Suggestions?
It sounds as though your quizzes array is either not sending KVO notifications or you're editing it in a non-KVO-compliant way (ie, "editing the array behind the controller's back").
Further, you might want to check into Indexed Accessor Methods for your quizzes array for performance reasons.
Related
I've got what (I would think) is an extremely simple case where an NSTreeController is bound to an array of root objects, each of which might have a few child objects. I am using an NSBrowser to show them.
They display fine and the hierarchy is correct.
The problem is the Tree Controller is not making any of the items editable. I want to be able to edit and remove (but not necessarily add) items. canRemove, canEdit always return NO, and the NSBrowser will not edit the labels.
The Tree Controller is marked editable and the count key path is not specified. "Conditionally sets editable" is set in the binding.
I am binding to "Content Array", not "Content", since the root level of items is an array.
Just to eliminate the possibility of mutability being a factor, The array and children are mutable arrays from readwrite properties (for now).
What am I doing wrong? Is binding through an NSTreeController not the right approach here? At this point, it seems easier just to revert to using a data source delegate.
UPDATE: stupid, but probably helpful to people who don't do Cocoa UIs every day (like me), so I'm leaving this question up.
I didn't have the selectionIndex bound between the control and the controller.
I am badly struck in a issue where I am trying to populate the nestableview lazily. Below is my approach.
I have created a custom class PRIList where it has an instance of array to manage the models.
I have bound the priList.items to the array controller in the xib where items is not an instance in PRIList but to support lazy loading I have implemented the methods countOfItems and objectInItemsAtIndex:.
Initialy when I populate the PRIList I populate few objects (say 50) with valid objects and rest with the faulty objects. In the objectInItemsAtIndex I check if the item at particular index is valid or faulty. If it is faulty I fetch next set of 50 objects.
What I understand is NSArrayController calls the method objectInItemsAtIndex for only the visible rows in the table view. But the problem here is as soon as set the PRIList the objectInItemsAtIndex method is called for all the objects. This is even called when some selection is changed in table view (the stack trace shows this method is called from [_NSModelObservingTracker startObservingModelObjectAtReferenceIndex])
Basically I want to fetch the records whenever the user scrolls down in the table view.
I followed the same approach in a different project in Lion. It worked there. Currently I am in Mavericks.
I tried overriding the isCompatibleWithResponsiveScrolling in the custom table view and returned it to NO. Still no luck.
Any help is very much appreciated.
First, have you assigned or bound the sort descriptors of the array controller? Or set any columns to automatically generate sort descriptors? (I'm not sure that latter is relevant. It depends on whether the column is sorted by default.)
In any case, if the array controller feels the need to sort the objects in order to arrange the objects, then it will need to load all of the contents. I was under the impression that it always does so, anyway, although you report that it works.
For an issue like this, I'd recommend that you go for full manual control. That means not using bindings or an array controller. Use a data source.
I have a view controller placeViewController which pulls in a bunch of Place objects, and from these loads and populates a matching bunch of PlaceView objects which are then displayed as subviews to its main view.
I need to update these views periodically which requires information from the model and other places to be pushed into the views
How should I properly structure this?
Keep an array of Place objects and give the model a PlaceView property to store pointers to the views
Keep an array of PlaceView objects and give the view a Place property to store pointers to the places
Keep both arrays and use a lot of indexOfObject objectAtIndex to jump between them
Some other way??
I need to update these views periodically which requires information
from the model and other places to be pushed into the views
You should really focus on an ObserverPattern. Yours views register to "notifications", and when changes are made, your registered views are notified.
http://en.wikipedia.org/wiki/Observer_pattern
You still can use NSNotificationCenter, but it will not futfill your needs since you need yours views make update per Place object (paired like a dictionary). So i recommend you to implement your own.
It will loose coupled because your controller will just only make glue between the observer and your views, and all the "logic" will be handled by the observer.
Well basvk got the answer in his comment but hasn't posted an actual answer for me to mark correct.
So here it is: "I would create a NSMutableArray with PlaceView objects. And the PlaceView class holds a #property Place *place"
I have a project that will have a lot of views (20 in total). They are displayed in sequence and the user makes certain decisions before tapping a button to make the next view appear. When all 20 views have been displayed, it goes back to the first view.
I also need to create a lot of instances of 3 different objects. So there may be 40 different instances of object1, 20 of object2, and 30 of object3. Each view needs to know about all of these instances and will often change instance variables.
I need to pass these instances between the views. I think I will do this by passing a pointer along to the next view. My question (I've finally got there), is where to create all these instances in the first place? In the original View Controller? Or in the AppDelegate?
Many thanks for any pointers (pun intended)
Usually you'd use CoreData for this. You start creating objects in initial view controller. Then after user manipulates the object you pass that object into next view controller (probably via UINavigationController) and create appropriate objects there as needed and so on and so forth.
On a side note - please rethink your navigation flow and user experience. User might be tired enough after as little as 5th configuration view.
Think MVC
When designing the model, consider diferent aproaches: CoreData, serialization in filesystem, in memory using singletone...
And remember: load lazily
I have a strong j2ee background, and I am trying to move to objective-c for some desktop/iphone programming.
I used many java web frameworks with mvc in mind, spring and struts ecc... so I am used to have servlet or controller which pass attributes to jsp pages, which is the view.
In jsp pages with jstl you can call this attribute and render to video.
In this way controller and view are (in theory) clearly separated.
With xcode, I can easily recognize the controller and the view built with IBuilder.
All the tutorial I found, shown the controller which go and change directly labels or text fields.
So my two questions:
seems to me that there's no separation between the two (controller and view), where I am wrong in that ?
is there a way for a controller to pack all objects in a kind of context in a j2ee way and have the view read that context ?
thanks
Leonardo
In most of the examples you have read you probably saw something like this:
[myTextfield setStringValue:myString];
now in this case sure the controller is updating the textfield directly, however as myTextfield is usually an IBOutlet it can be any textfield in your view, or even nil. quite possibiy it doesn't even need to know that it is an NSTextfield just that it responds to a setStringValue method. In this sense there is a seperation between the controller and view.
Now in your comments above you were concerned with seperation of responsibilities within MVC but did not mention the model much. With Cocoa bindings you can bind directly to model keypaths, in this case the model neeed not know anything at all about the view.
MVC is a bit of an ambiguous concept with no hard definition. It can mean different things to different people. For me it means that the view has knowledge of the controller ( through outlets or bindings) limited knowledge of the model(through bindings). The contoller has full knowledge of the model and limited knowledge of the view(through outlets). Finally the model has zero knowlege of the view and ideally no knowledge of the controller.
With regard to your second question, I don't use j2ee, but I think you can acheivee what you want by having your controller update a context ivar ( probably a NSDictionary) then in your view bind to this context with a keypath. However there is no real need to wrap everything up bindings are very versitile and u can bind to any property.
I do not understand your second question (I've never used J2EE), but I think I can make some headway answering your first.
Cocoa does not enforce MVC; it just strongly encourages it -- especially for larger projects. Consider an example program, one that has an NSTableView bound to an NSArrayController.
In this case, the NSTableView is clearly the view (it has the word "view" in its name) and the NSArrayController is clearly the controller (it has the word "controller" in its name).
The model is an NSArray that the NSArrayController knows about, but you probably don't interact with that model directly. You will instead ask the NSArrayController to manipulate its model by sending addObject: and removeObject: messages to the array controller (and not to the array itself).
When you do this, the NSArrayController will effect a change in the NSTableView via bindings. Again, you don't ever ask the NSTableView to do anything.
So you never talk to the view and you never talk to the model. Everything you want to happen goes through the controller.
MVC. QED.
Of course, maybe the way your project works, the view should be its own controller. The world won't end, although you might find it to be a little more difficult to go against the grain of the framework. But you should always try to use the best approach for the job at hand instead of insisting on some sort of design pattern purity.