I have NSCollectionView with full of items, have one scenario where after deletion of one item the collection view should be refresh and it should display update items.
I am able to delete item, but collection view is not refreshing,
googled a lot, but got nothing,
NSCollectionView is a subclass of NSView. And you must be knowing MVC design pattern. View is intended only to show the data/values from the model.
In your case you must have some array. You need to update the array and set the content of NSCollectionView programmatically or using Cocoa Bindings.
- (void)setContent:(NSArray *)content;
Also you may need to refresh the view :
[yourCollectionView setNeedsDisplay:YES]
Anoop's suggestion didn't work for, but following did, copied from here
Turns out that the NSCollectionView item views can be refreshed by setting the ItemPrototype, e.g.,
ItemPrototype = new SomeViewController()
This causes all the existing views to be recreated.
Related
I have a collection view and each item has an image and a label. I want to click the NSCollectionViewItem or NSImage and then hide the collection view and display a completely separate view containing the details of the object that was clicked.
I cant find any documentation on how to handle click events in this situation. How is this possible? I have built out the collection view in Interface Builder so everything was done via bindings as opposed to code.
#Jeff, I don't have permissions to add a comment so writing this as answer.
You can overwrite setSelection in your subclass of NSCollectionViewItem (as explained by #indragie in Selection Highlight in NSCollectionView) to track the selected item and perform an action.
The solution that I went with was to not actually use an Image Well, aka NSImage. I used a button and bound the Image property to an instance of an NSImage that I exposed as a property on my model.
It was easy enough but I'm shocked more people havent been asking this question.
Sometimes IB simply doesn't allow you to add a view as a subview to a UIViewController as illustrated here
If I drag a UIViewController from the object library and try to embed it within Mailbox View Controller.. it doesn't highlight, however it would work fine if I try to add it to the generic View Controller at the bottom (can the fact that Mailbox View Controller have a Customer Class MailboxViewController have anything to do with it?)
I'm pretty sure I can do this programmatically (which is what I'll try next) but I was wondering if there was a reason for this (and if there was a way around it).
update:
this is what i'm trying to accomplish: I was following the steps here to implement a segmented view controller below search bar like in the iphone mail app.. however I kept on getting an error saying that a view can only belong to one view controller at a time.. So what I'm trying to do is basically create a separate viewcontroller, reference it from MailboxViewController as an outlet, make the containing view of my search area the view of this new view controller (this is where i'm getting stuck) and finally make the searchContentsController property of UISearchDisplayController refer to the view of this new view controller. (if this sounds confusing, which I know it does, please refer to this answer)
From your screenshot, the view property of your mailbox view controller is a table view.
A table view in interface builder won't support the dropping of arbitrary views onto it as subviews - where would it put them at runtime? In IB the table has no content, it just has that visual representation of cells to let you know what it is.
You haven't said what you are trying to set up so I can't offer any additional help. Adding a subview programmatically to a table view probably won't give you the effect you're after either - a table view is a UIScrollView subclass, so your new view will either move off screen or get covered up by the table view adding cells.
I'm not sure if this is a feature or a bug, but when I have two collection views on a view controller using the same instance of UICollectionViewFlowLayout, an interesting thing happens. Note that I'm not using Interface Builder / XIBs for any of this; I'm laying everything out in code.
The first UICollectionView has twelve cells in it, but the second one has 20. When I reload both collection views, both act as if their contentSize property has 20 cells in it. This means that when I scroll to the right of the first UICollectionView and get past the first (and only) 12 cells, my app crashes (because I'm pulling data from an array that only has 12 cells' worth of data).
To get around this for now, I'm instantiating two identical UICollectionViewFlowLayout objects and assigning each to its own collection view. Is this normal behavior?
I'm only getting started writing code with UICollectionViews, so forgive my ignorance if I'm exuding any!
Don't do this. A collection view and a layout object should be a 1:1 relationship. The layout object has a property, collectionView, which obviously can only hold a reference to one collection view.
When the collection view then asks the layout for its size and so forth, the layout object is going to base everything on the second collection view you assigned the layout to, since this will be held in the collectionView property.
I couldn't find an explicit statement in the docs not to share a layout object between collection views, but the property discussed above should make it clear that this is not an intended use.
I have two table views and a detail view being managed by a UINavigationController. When a row is selected on the second table, it pops to a detailed view allowing changes specific data represented by the row. I need to be able to switch between the UITableView and the UIViewController without losing any of the data that might have been changed in the UIViewControllers (button selections, text values entered in fields, etc).
Basically, once the UIViewController is presented, one should be able to switch back and forth between the table and detail view without losing any data.
The problem is, when a UIViewController is popped from the navigation controller, that memory is automatically released, and since I'm using ARC, I can't just keep a pointer to that with a retain command in the UITableView.
I know that I could manually rebuild the view each time its corresponding table row is selected, but I feel that might be a messy solution. Another option I've thought of is keeping an array of pushed UIViewControllers and checking if the selected table row corresponds with an existing value before a new one is created, but that might also get messy.
Any suggestions?
Your final wish in this back and forth of view is what you stated in your question: you want to switch between view controllers without losing any information of the actions performed in these controllers.
But if you think at how MVC pattern works, you should consider a view controller as the glue logic between the view and the model. The view is not persistent, that's why it is legitimate for ARC to get rid of the owning view controller when the view is no more needed. Instead what you should persist while your app is working is the model data only: the model data will be shared between the involved view controllers, the view controllers will be recreated each time and the corresponding views will be updated based on the model data. The only reason why the view controller should be kept alive is when its alloc-init-loadView takes too much (e.g.: the view is OpenGL backed) but in such case I would suggest you to keep a strong reference to it in the AppDelegate and ask it to refresh the content when the model data is replaced.
So basically what you should do is:
- select the table
- extract the model data associated to the table, including all information relevant for the view controller
- push the view controller; save all view modifications to the model
- when the view controller is popped, the model data will be returned only
- next time, when you push the view controller again, you will restore the model and re-init the view controller.
This approach is not complicated and gives you the possibility to structure the app in a clean way. Tomorrow you can change your view controller structure (that its view and the logic) without any impact in the communication with the other view controllers as this managed by the model passing only.
There are a couple of solutions to this, just like you suggested.
The array solution is highly inefficient because of memory issues.
The second solution you proposed is a lot more elegant. Just write your own init method in that view controller and init the view controller with data from a plist file
If I'm reading the question correctly, you've got a tableView and a detailView that are driven by the same model data. When changes to the model data are made in the detail view, you want those changes to persist.
If you update the model based on the state of the controls when the detail view is popped, then those changes will persist and the changes will be visible the next time you drill back down into the detail view.
You don't mention what form the table data takes, but let's assume it's an NSArray of NSMutableDictionaries. When you tap the row, the didSelectRowAtIndexPath: method will need to hand the dictionary from that array index to the detail view controller through a property on the detail controller. The detail view controller will update the dictionary values in the method that dismisses it.
The way to think of this is using the model-view-controller pattern. The table and detail view data is stored in the model; the views present the data; and the controllers are responsible for updating the model and navigating between views.
I've got an NSTableView that displays (via bindings) data from an NSTreeController. The application frequently appends/changes data to/in the bound array.
The problem is that if the user has selected a row in the table, but has scrolled so that the selected data is no longer visible, when the application updates the array it causes the display to auto-scroll so that the selected line is once again on screen. This is pretty
frustrating to users, especially since new data can arrive at any time.
Is there any way of disabling this feature?
You may have to subclass NSTableView and override -scrollRowToVisible:, temporarily bracketing the call to super. This may also require a custom BOOL ivar in your subclass to keep track of whether you want to scroll.
I would start by setting a breakpoint there to see when exactly the autoscroll is triggered. This should help to find the proper moments to toggle the ivar.
Are you using an NSTreeController with an NSOutlineView or an NSArrayController with an NSTableView? Using an NSTreeController with an NSTableView doesn't make a lot of sense to me?
If you're using an NSTableView you should probably be using an NSArrayController to manage its data and this rearranging of the rows is a feature of the NSArrayController. Try turning off the Auto Rearrange Content option on your controller within IB.
When it's on, the array controller will rearrange its objects on addition, removal and changes to objects that would affect the sort ordering (if any) and cause any table views or outline views to reload their data.
I don't know of a similar feature for NSTreeController mainly because I don't use it since it's never worked well for me. I, sadly, recommend to just use the datasource methods for the NSOutlineView and supply your data the old-fashioned way. In my experience, NSTreeController is only well suited for the most trivial tasks.