I see UIScrollView has a method to predict final content offset
scrollViewWillEndDragging:withVelocity:targetContentOffset:
and since UITableView is also a UIScrollView, So I want to use this value to calculate the destination Cell while the view is still scrolling/decelerating
I'm trying to loop through all the data and sum up the section headers, cell heights, section footers until the sum exceeds target Content offset. Would it work or is there a better way to do so?
Thanks in advance, any help is appreciated!
Leo
Don't use that method to predict where your table view will end up and try to guess which cells to load content for. Optimising table scrolling, particularly the loading of images, is a well-known problem. Check out this WWDC Video (developer registration required) and Apple's sample LazyTableImages project. Basically, you start background operations to load your cell contents, and update the cells (if they are still on the screen) once your content is loaded. In the meantime, you show placeholder content.
If you do it the way you intend, you will only ever have the target cells populated,which will look odd as you are scrolling past cells that have never been the target.
Related
I'm using UICollectionView to build UI that can display elements in a grid or a vertical list layout. UICollectionViewFlowLayout doesn't play well with a full-width list layout, so I'm writing my own UICollectionViewLayout subclass. And the rows are self-sizing, so that they can have multiline labels and match their font size to the system font size setting and grow/shrink as needed
Internally, it has a collection of layout attributes for all rows. In prepareLayout (prepare in Swift) I walk over all index paths in the data source and create layout attributes with their frames set for an estimated row height.
In shouldInvalidateLayoutForPreferredLayoutAttributes, I return YES if the height is different than the value I have for that row in my collection. Then in invalidationContextForPreferredLayoutAttributes, I invalidate all items after the index path of the passed-in preferredAttributes, because a height change in this row affects the vertical position of all subsequent rows. Then prepareLayout gets called again and I update the frames of everything as necessary.
The problem comes with this sequence of events:
layoutAttributesForElementsInRect gets called. I walk over all my attributes and check if CGRectIntersectsRect(attr.frame, rect).
shouldInvalidateLayoutForPreferredLayoutAttributes gets called for each row that is about to appear. Some of them end up smaller than the estimated height they had originally.
If the total row shrinkage is enough, a row or two that weren't within the rect for layoutAttributesForElementsInRect get moved up enough that they should appear. For example, if the rect was y values 0 through 1334, a row with y origin 1340 before the calls to shouldInvalidateLayoutForPreferredLayoutAttributes could now be at 1300. But the layout object already "knows" what rows are supposed to be onscreen, so those rows just don't show up, and there are holes in my list.
I might be able to work around this by returning extra rows from layoutAttributesForElementsInRect (by expanding the rect I get by 100 points vertically or something). But that's a hack, and this seems like something that the APIs should have a way to address. But I don't get another call to layoutAttributesForElementsInRect after self-sizing is done, and I don't see a way to ask for it to be called again via UICollectionViewLayoutInvalidationContext.
So...am I missing something obvious in the API? Is this a problem that shouldn't be happening, which means I'm approaching something wrong? It seems like there's no way to accurately answer layoutAttributesForElementsInRect before self-sizing has happened...?
Example code illustrating the problem is here on GitHub.
I've discovered that having extra invalidations in invalidationContextForPreferredLayoutAttributes when you have self-sizing supplementary views will cause a bug where you get layout gaps. I've made the same mistake and others have too because it seems logical to invalidate the items below and item being self-sized. My guess is that the collection view handles this for you.
These are the lines to remove in your sample project:
[result invalidateItemsAtIndexPaths:rowPaths];
[result invalidateSupplementaryElementsOfKind:UICollectionElementKindSectionHeader atIndexPaths:headerPaths];
I've filed a documentation update Radar with Apple about this.
http://www.openradar.me/35833995
My proble was that layout attributes that I was returning from my custom layout were missing zIndex property so self-sizing did not work properly.
i want to make a transparent table view but the problem is that when the cells go behind the section headers the texts overlapps(see the image:)
http://www.imagebanana.com/view/4lu0pp8s/Bildschirmfoto20130920um13.20.45.png
my idea was to draw the part of the backgroundimage in the header as background but the drawrect method is not updated when the cells are moved.
Hope someone can help me
You need to trigger a call to -drawRect: yourself by calling -setNeedsDisplay or -setNeedsDisplayInRect: on your header. You will probably want to trigger it based on detecting the position of the header in -scrollViewDidScroll:.
Warning: you will want to figure out whether you need to draw the header and then call -setNeedsDisplay as infrequently as possible. Bitmap drawing is slow, and can cause the UI to stutter. You should only need to do it when a header row hits the top.
If your header rows are all the same size, cache the image after the first time you draw it, and then just reuse it each subsequent time you need it.
How would I go about setting a custom background image for a UITableView. The wrench in the works is that the table is a grouped style (rounded top corners for the first cell and rounded bottom corners for the last cell). I would like do this as much in code as possible without relying on images too much.
Ideally, here is the solution, but I have no idea if this will work or not:
Create one custom background image
Apply the same custom background image to every cell
Rounding occurs automatically because it is a Grouped table style
Profit.
Is this how it works (besides the profit part... I am an app developer, after all)? Do I need to re-think my approach or is this possible? How would do what I described (or another approach) in code specific to iOS 5+?
Update
Just to clarify a bit, the main question I'm asking is: Does the rounding still occur on the top and bottom cells even if you are using a rectangular image?
Well I think what you are saying is ok, but I suggest creating a unique cell layout in a .nib file and apply there the background. Then, with initWithNibName you can manage every cell at the UITableView's methods on the ViewController.
I have a NSTableView which is a list of a custom NSTableCellView (only one column). The problem is, after resize and/or scroll and/or some NSPredicate filtering, some rows are not shown, only a blank cell in the row, but there is a NSImage picture is shown correctly, ALWAYS, wonder if this has something related with NSTableCellView.imageView.
I think this has something with the scroll/cache settings inside NSTableView, but I just don't have experience on Cocoa guessing where to begin. The table view is cocoa bound with NSArrayController, which uses core data for storage. Thanks a lot for helping :)
This is very strange behaviour, but something that I have observed.
I was using hi-res artwork (300x300px images) and allowing the NSTableCellView to scale the image down. When I supplied the table cell view with 20x20px images the text was never missing.
I'm developing an application that requires me to display many short strings of text in table cells. Currently, I'm using a default table view cell with about 14 UILabels added. Half of these labels contain static text that will not be changed, while the other half contains dynamic data that has to be updated when the table is scrolled.
As my clients are complaining that the table is lagging, I am wondering if there is a more optimized way to display the data, and improve scrolling performance. For example, would the table cells render faster as the table is scrolled if the fixed text is rendered directly onto the view, instead of being contained in UILabels? What other methods can I use to improve scrolling performance?
Performance issues in table view scrolling can be caused by any number of issues. For example:
Make sure the UILabels are opaque to avoid blending. (You can select the color blended layers option in the Core Animation instrument to verify this).
Make sure you're recycling table view cells by using dequeueReusableCellWithIdentifier:
It might be helpful if you could post your implementation of tableView:cellForRowAtIndexPath:
additionally to anshuchimala's answer i would recommend you to remove the static labels and integrate it into a UIImageVie which you use in your tableviewcell as a background image.
Apart from that opacity (as mentioned by anshuchimala) is a big performance-blocker, but also the extensive use ofNSDateFormatter instances can vastly decrease your performance (especially the instantion of NSDateFormatter instances need a lot of power)