Transparent TableView without overlaping elements ios - objective-c

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.

Related

Select CollectionViewCell when scrolled into view

I have a collection view that is 100 points wide with a number of cells that are each also 100 points wide. I've got it setup to support scrolling and paging horizontally so the user can flick left and right and each cell occupies the entire collection view frame.
Originally, I had no scrolling and the user would tap each cell to activate something in the app. Now that its a narrow frame where only one cell can be seen at a time I feel that tapping is redundant and the cell should simply be tapped in effect when it comes in view.
Is there a way to trigger an event such as didSelectItemAtIndexPath when a given UICollectionViewCell becomes the one displayed within my collection view's frame?
UICollectionView responds to selectItemAtIndexPath:animated:scrollPosition:.
It also responds to indexPathsForVisibleItems which will be useful to determine where to make the selection.
You also need to decide when to make the selection, probably best after receiving scrollViewDidEndDecelerating: which the delegate inherits from UIScrollViewDelegate).
But it may be even better advice to look at what your code does upon selection and just do that (launched from the same place in code, probably when scrolling is finished), leaving selection out of it.

Content offset while Inserting item in UICollectionView?

I'm using performBatchUpdates: to insert a new section to my collection view. This comes with the default fade in animation that I'd like to keep. The item I'm inserting is always the last item, so I'd like to offset my collection view to the bottom to make it visible.
Right now I'm able to achieve this by using scrollRectToVisible: in the completion callback of the batch update method. However, by the time it scrolls, the fade in animation already happened out of frame.
I'd like for both to happen simultaneously. Is this possible?
One approach I've tried is pre-calculating the new size manually ahead of the updates and scrolling first, but then the cells get reused right on screen, appearing and disappearing, which is not ideal.
Any ideas?

predict table view scroll destination indexpath

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.

How to Insert/Remove/Update UITableView without it appearing to move?

After reading this, I'm interested in being able to dynamically update a UITableView without the view scrolling. That is, if the 12th row is visible, and some background process runs and calls for a new row to be inserted at position 0, how can that be done without the table appearing to scroll?
The closest I've been able to come to achieving this is to do any and all updates in a single -beginUpdates/-endUpdates block and to adjust the contentOffset as appropriate after that. But some of my code might have a bunch of calls to -insertRowsAtIndexPaths:withRowAnimation called outside such a block, and when I do that, the thing can scroll all over the place.
How can I make UITableView stand still?

How can I scroll a UIView of indefinite size within a UIScrollView

I'm trying to draw a graph that is indefinitely large horizontally, and the same height as the screen. I've added a UIScrollView, and a subclass of a UIView within it, which implements the -drawRect: method. In the simulator, everything works fine, but on the device, it can't seem to draw the graph after it reaches a certain size.
I'm already caching pretty much everything I can, and basically only calling CGContextAddLineToPoint in the -drawRect: section. I'm only drawing what's visible on the screen. I have a delegate to the UIScrollView which listens for -scrollViewDidScroll: which then tells the graph to redraw itself ([graphView setNeedsDisplay]).
I found one method that tells me to override the +layerClass method and return [CATiledLayer class]. This does allow the graph to actually draw on the device, but it functions very poorly. It's incredibly slow to actually draw, and the fade in that occurs is undesirable.
Any suggestions?
Well, here's my answer: I basically did something similar to how the UITableView works with cells: I have an NSMutableSet of GraphView objects which store unused graphs. When a section of the scroll view becomes visible, I take a graph view from that set (or make a new one if the set is empty). It already had a scrollX property to determine which part of it was supposed to draw. I set the scrollX property to the correct value and, instead of using the screen width, I gave it an arbitrary width to draw. When it goes out of the scroll view, it is removed from the UIScrollView and added to the set.
I wonder though if I really even need to remove them when they go outof the view? It may be prudent to try leaving them in and remove the ones not on screen only if I get a low memory warning? This might get rid of the pause whenever it needs to redraw a section of graph that hasn't changed.
My saving grace here was that my GraphView already was set up to draw only a portion of the graph. All I needed to do then was just make more than one of them.
I think this is a limitation of the iPhone graphics hardware. Through experimentation, I have seen that the iPhone will refuse to draw a frame that is bigger than 2000 pixels in either height or width. It probably has something to do with limited size for frame buffers in hardware.
Watch the 2011 WWDC session video entitled "Session 104 - Advanced Scroll View Techniques".
Thanks, that's helpful. One question -- what did you use for the contentSize of the UIScrollView? Does UIScrollView tolerate large content sizes (over 2000 px) as long as you're not creating buffers to fill the entire space in your content view? Or are you keeping the UIScrollView a constant size (say, 2 screen widths) and resting the UIScrollView contentOffset property each time you draw (using scrollX instead of the contentOffset to store your position)?
I think I answered my own question (the latter seems like a better alternative), heh, but I'll go ahead and post this in case other people need clarification.