performa 640 pizza live
> On Aug 10, 2016, at 10:29 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> 
>> On Aug 10, 2016, at 11:10 AM, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> I'm currently trying to implement something that seems basic but has been 
>> driving me nuts: making a Collection View with cells that are dynamic-width 
>> and height at runtime.
>> 
>> I was able to accomplish this with Table Views by using the dynamic height 
>> constant. Following Apple documentation, I set the width of the table view 
>> cell in IB to be an arbitrary size, for example using the default 600 
>> pixels. I then use autolayout to make the size/position of the table view 
>> subviews adjust to the size of the cell. At runtime, the table view sets the 
>> width of the cell, and autolayout can change the height based on the content 
>> (e.g. multi-line labels.)
>> 
>> Now I want to do this using a Collection View. Reading Apple's documentation 
>> and watching the relevant WWDC video, it looks like this will be just as 
>> easy, right? As is my experience working with Collections, nothing ever 
>> comes easy.
>> 
>> OK, so I do basically the same thing as I was doing with tables.
>> 
>> • Create a Collection View Controller in a Storyboard.
>> • Create a collection view cell in the collection view inside the Storyboard.
>> • Make the cell the width of the collection view.
>> • Add some labels that fit the width of the cell using autolayout and allow 
>> for multiple lines (e.g. dynamic height)
>> • Use the default flow layout in IB and set the item size in the flow layout 
>> to be something less than the size of the collection view.
>> • Make sure section insets are 0.
>> • At runtime during viewDidLoad for the collection view controller, set the 
>> item size and estimated item size in the flow layout to be something related 
>> to the size of collection
>> 
>> I run this and behold…it crashes. And there are lots of warnings:
>> 
>> "The behavior of the UICollectionViewFlowLayout is not defined because: the 
>> item width must be less than the width of the UICollectionView minus the 
>> section insets left and right values, minus the content insets left and 
>> right values."
>> 
>> This is kind of odd since I go through a lot of trouble to make sure the 
>> cell item size is not too big. Here is what I see for the item size: Yet the 
>> app still crashes due to a cell that is too wide for the collection.
>> 
>> So, somewhere else the item size is getting set behind my back to something 
>> other than what I set in itemSize, estimatedItemSize, cell bounds, etc.
>> 
>> Before I go any further, I wanted to see if there's an official way to 
>> accomplish my goals without doing way more work, that is having to subclass 
>> the flow layout class. Should the default flow layout class even be able to 
>> do this? I see a lot of different ideas on the interwebs that involve doing 
>> things with the flow layout but I'm hesitant to go down that path. Shouldn't 
>> this very basic use case be doable without having to get into the complexity 
>> of the layout class? Honestly, the documentation for this is terrible. 
>> There's a lot of hand-waving and assumptions that don't quite spell out most 
>> of the details of this use case.
>> 
>> Thanks.
>> 
>> Doug Hill
> 
> Digging into this a little deeper, I find this tidbit in Apple documentation
> 
> =============
> 
> UICollectionViewFlowLayout: estimatedItemSize
> 
> The default value of this property is CGSizeZero. Setting it to any other 
> value causes the collection view to query each cell for its actual size using 
> the cell’s preferredLayoutAttributesFittingAttributes: method
> 
> =============
> 
> OK, this makes sense why my cells all ended up with the wrong size. The cell 
> class needs to override this method to set the cell's size instead of all the 
> other ways I used above.
> 
> Remember, my objective is to make the cell width be the same width as the 
> collection view itself. Huh, collection cells don't have a reference to the 
> collection view it's contained in. Given that I don't know how wide the 
> collection view is, I'll pick an arbitrarily small width so at least the app 
> won't crash. Let's say 300 pixels. I call the cell's super implementation of 
> preferredLayoutAttributesFittingAttributes and then change the frame property 
> of the layout attributes it returns.
> 
> Progress! The app no longer crashes right away and the collection cells now 
> have my adjusted width. I do see a couple of problems though:
> 
> 1) The height of the cell is wrong
> It seems to use the default height of the cell as it is layed out in the 
> Storyboard, not the new height of the cell based on my autolayout 
> constraints. This is pretty much the entire reason I'm using the 
> estimatedItemSize property in the first place; it's supposed to figure this 
> out for itself. Ugh.
> 
> As a workaround, I can calculate what the height should be based on the 
> origin and height of the multi-line label, and change the layout attributes' 
> frame property to use this.
> 
> 2) The app still crashes
> When scrolling, it will show some number of cells correctly, then I'll see 
> one that has an incorrect width and the app crashes. The crash happens inside 
> the call to the cell's super implementation of 
> preferredLayoutAttributesFittingAttributes, and happens whether I update the 
> height as in #1 above.
> 
> OK, so now there is some unsafely when updating the layout attributes 
> returned by calling super's preferredLayoutAttributesFittingAttributes. 
> Digging around in the Apple docs I don't see any mention of anything about 
> how this might be unsafe.
> 
> Again, looking for any ideas, pointers, etc. about any of this, including 
> whether I'm going about this the wrong way.
> 
> Doug Hill
> _______________________________________________
> 
> 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/nkozic%40fdn.fr
> 
> This email sent to nko...@fdn.fr


_______________________________________________

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

Reply via email to