I have different NSCollectionView's that use NSCollectionViewDelegate. When I use a Flow or a Grid layout, the delegates functions are called, but not with the Content Array (Legacy) layout.
Of course the collectionView.delegate is set correctly as it works with other layout.
Does somebody know why?
Thanks.
Related
I found a couple examples that work but only with UICollectionViewFlowLayout. Does anyone knows how to implement this with NO UIcollectionViewFlowLayout
UICollectionViewFlowLayout is for showing the items in grid format.
You can use your custom layout inherited from UICollectionViewLayout and set it to collection view layout.
Even gallery implementation of the most of the apps is done using collectionview.
I am using a UIPageViewController in my app to display number of images (1024x768 size). Is it ok to make array of UIViewControllers each with his picture and in set appropriate for each page? Maybe if you get like 50 pictures it will crash? At the moment I store images in Documents folder so I can remove images from view controllers that are not on screen
This wouldn't be very efficient, you'd be much better off doing the same thing with UIImageViews. Even then you have to be careful. Probably the best way to handle this would be to using image views and deallocating them when they go more than one image width out of the screens bounds. Then of course reallocing when the image in question is the next image in line to be displayed in either direction.
EDIT: It looks like you can use the following UIPageViewController Datasource methods to set which view controller do basically have queued and waiting to the right/left. Using these you should be able to only allocate 3 view controllers at a time.
– pageViewController:viewControllerBeforeViewController:
– pageViewController:viewControllerAfterViewController:
Then you can use this to set the initial controller:
Set the initial view controller using UIPageViewController's
-setViewControllers:direction:animated:completion:
The sentence below is quoted from Apple's documentation and is leading me to believe that the controller may be able to only load the necessary view controllers into memory on its own.
View controllers are either provided one at a time (or two at a time,
depending upon the spine position and double-sided state) via the
setViewControllers:direction:animated:completion: method, or provided
as-needed by the data source. Gesture-based navigation is enabled only
when a data source is provided.
Ok, so I have this issue where I need to get access to the headers/footers displayed in a UITableView. Moreover, I need to do this from a subclass of UITableView (so I can't simply assign tags to the view from the UITableView Delegate). UITableView does keep an array of visible headers and footers but it provides no access to those arrays even to the subclass, which I personally think is asinine.
I need this so that I can provide a custom drag-n'-drop insertion/move user interface. I'm trying to get it to work almost exactly like Apple's own rearranging interface, but of course, with my own custom implementation (like the ability to drag from another table). Everything works perfectly except for the headers/footers.
At the moment I'm trying to hack it by iterating through all the subviews of UITableView. I'm pretty sure that the only subviews of UITableView is: backgroundView, UITableViewCells, and Headers/Footers. So I just need to determine which are UITableViewCells (very easy), which is the background view (also easy) and which are headers/footers (not so easy). I'm pretty sure I can do it this way but it's definitely a hack and I'd rather find a better way if possible.
UPDATE
I'm overriding the - (void) setDelegate:(id<UITableViewDelegate>)delegate method and checking to see if the delegate responds to the appropriate selectors to generate headers/footers (and set BOOL's appropriately). This is making it a lot easier to determine what a particular subview is since the progression of header -> cells -> footer is predictable.
You say you can't use UITableView delegate methods, but did you consider letting the UITableView subclass object be its own delegate? Create a separate property on the subclass called realDelegate and pass any other delegate calls through to that.
While I have made great strides in customizing an NSCollectionView, thanks to hints I've gleamed here and across the web, I am having a bit of difficulty I'm hoping someone can help with. I have a Core Data entity that contains information about Video files and a NSCollectionView that displays a thumbnail image preview of each of these videos. I have bindings setup on the NSCollectionView.
On my first attempt at setting up bindings, I setup my Array Controller in Class mode and tied it's content to an NSMutableArray that I was filling with all of the objects from my Videos entity in windowDidLoad. I was performing addObject on the array controller to get them to show up. This works fine except for the fact that it takes quite a while if you have a lot of objects to load.
So... It seemed silly to me to copy all of the objects to an array when it's possible to bind a NSCollectionView directly to Core Data. I changed my ArrayController to Entity mode and setup the Managed Object Context to point to my App Delegate's managedObjectContext. When I launch my application, there is a delay before the Window displays on screen. In fact, the other things I'm doing in windowDidLoad process immediately, but it takes another 5-10 seconds for the window to display. Once it does, nothing is showing in the NSCollectionView.
I initially thought it just was not working until I accidentally resized the Window and all of the items showed up in the collection view. I've tried to see if there is a way to know when the Window is actually displayed so that I can call [collectionView setNeedsDisplay:YES] but either it doesn't work or I'm not calling it in the right place.
Does anyone have an idea why the objects are not just showing up? I'd also like for the Window to display immediately and then for the Collection View to load the items from the Core Data. Loading directly from Core Data seems much quicker than copying the items to an array. I'd be happy to post any code you'd like to see although since the bindings are setup in IB, there is not much to show. :)
Thanks!
I am making a UIView-based class for use as a tableHeaderView. It will have several controls that will be based on edit mode - some will appear/disappear and some will change appearance when it switches modes. The height of the view itself will change when it switches modes. Seeing that the layout will change a lot, I decided it would be better to just make the whole thing programmatically than to try to lay it out in a nib.
What I am struggling with is where the view/controller separation should be. Should the viewcontroller have an object for each control (UITextField, UISegmentedControl, UIButton, etc) or should it just have an instance of my UIView-based class?
Where should the code that actually creates the controls and sets the properties reside? Should my view have a method that gets called to set the entire view (based on edit mode) or does this put too much power in the view that should be in the controller? Should the view only set the positions of the controls? Or should there not even be a UIView-based class - the view controller will declare and configure all the controls by itself?
What is the proper MVC separation here?
jorj
The MVC rule of thumb is that your controller is the go-between – if your model is storing information about the edit mode, then your code will be cleaner if the controller does the work. If the edit mode settings are discarded when the view goes away, then the controller doesn't need to know about them.
It's also worth considering whether this code will be re-used – if you're creating a view that you're going to use again elsewhere, that may make it easier to decide where the "brains" of the code should reside.