So I have a UITableViewController. The cells in this tableview have the following UIControls:
2 UILabels, one of which has a shadow and a clearColor background color.
1 Custom Progress view resized to be larger and with a different color
3 UIButtons
Functionally, they do exactly what they are supposed to do. However, I've noticed when looking at it on device that scrolling performance quickly tanks and has dropped frames all over the place, even with other interactions like pushing one of the buttons.
So I was reading around today and found http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/ this article by the Tweetie guy about how to achieve fast scrolling performance by subclassing UITableViewCell and doing the drawing yourself.
The example works extremely well, but when I tried to adapt it to work with my desired configuration I realized that he isn't using any predefined UI Controls, he's mapping out everything by hand.
While I can see how this would be an extremely efficient way to do things, it strikes me as problematic for things like the progress view and the buttons, and even one of my labels to a certain extent.
So my question is this: Do I need to completely write my controls from scratch if I want my scrolling performance to be good, or is there a way to use the standard UI Controls and get good scrolling performance?
If you're adding custom controls to your cell, you should still be subclassing UITableViewCell, adding your controls in the init function, laying them out in layoutSubviews, etc. - just like any other view. As VdesmedT says, make sure you're re-using cells via the dequeue mechanism, so that you aren't allocating new cells with each scrolling operation.
OK, I will propose something obvious but to achieve UIScrollView performance, you need to be sure that the dequeue mechanism works well. I often see developers not properly set the identifier in IB and therefore missing the UITableViewCell cache benefit
Related
I'm creating custom UITableViewCells, and I'd like to make them in a way that allows the table view's scrolling to be as smooth as possible. In their current state, with a custom background image on each cell using the cell's backgroundView property, scrolling is is still fairly smooth.
But my question is, how can I add content to the cell and maintain this? The cells are fairly different from each other -- one may have a single label, another may have two labels and an icon, and another may have a bunch of other controls.
I've found that using unique cell identifiers for non-similar rows makes the overall experience laggy, so I need a method that allows me to use the same cell identifier and have very different cells.
Should I be using an XIB for this? If not, how should my subclass function? I was thinking of adding all of the controls to the cell, and only hiding/using the ones necessary at the time. Is there a cleaner way?
I've decided that I don't want to ever use UIPickerView again... it's completely inflexible in terms of functionality, design, and size (height). It also occasionally gets stuck between rows, and the delay that occurs between letting go of a wheel and when the delegate method is fired indicating that a new row has been selected (because of the "settling in" animation) has caused lots of problems in the context of the apps I've been working on.
That being said, the user-friendly aspects of UIPickerView are good, and I'd like to try to replicate it. I've tried to research different ways that this might be done, but without much success. Does anyone have any ideas as to what would be involved to make something similar from scratch?
I was trying to get a UITableView subclass to behave in such a way that whatever cell was currently in the middle of the table (it would change while dragging, etc.) would change its background colour to something different implying that it was "selected". As soon as the table was dragged such that the "selected" cell was no longer in the middle, the cell would go back to normal and the new middle cell would change colour. So this would be like UIPickerView in a sense that you don't have to tap on a cell; instead you just drag to have one selected by default.
I figured it should have been easy enough to intercept the "touchesMoved" method of UITableView and add some code that looped through all currently viewable cells in the table, checking to see if their frames overlapped the center point of the table, and changing their appearance accordingly (plus sending a notification to other classes as needed to indicate the "selection" change). Unfortunately, I can't get this to work, as the "touchesMoved" method doesn't get called when I drag the table. Am I missing something obvious?
Any ideas or suggestions would be very much appreciated at this point... I made an app that relied heavily on UIPickerView objects, and because of the problems I've run into with them, I'll have to abandon it unless I can figure out a way to make this work.
Thanks very much,
Chris
Remember that a UITableView is a subclass of a UIScrollView, and the UITableViewDelegate gets all the UIScrollViewDelegate method calls too. scrollViewDidScroll: sounds like it would easily fit the bill for knowing when the table view was scrolled.
As for finding which row is in the middle of the view, just use indexPathForRowAtPoint:.
I have a UIScrollView that I am using to simulate a UITableView like interaction because rows are a bit more complex than what UITableView has to offer. I have 4 UILables a UIImageView and a UIButton for every row. The end result is a lot of subviews.
Even with only 10 rows,the scroll view that looks fine in the simulator but has a fairly low frame rate on the iPhone 4. This is a resource consumption issue for sure.
Is there a way to optimize the redraw durring scrolling like double buffering?
If not is there another way to get customizable UITableview functionality?
thanks
Does every View have 4xUILabels, a UIImageView and a UIButton?
I would create a nib file with a custom UITableViewCell (You can make those as complex as you want), then you can reuse the cells to help with your performance.
Information on how to do this is here:
http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/TableView_iPhone/TableViewCells/TableViewCells.html#//apple_ref/doc/uid/TP40007451-CH7-SW1
I think you probably want to create a custom subclass of a UITableViewCell as the UITableView will handle all the redrawing for you. In a custom UITableViewCell you can add as many subviews as you like.
Take a look at http://cocoawithlove.com/2009/04/easy-custom-uitableview-drawing.html.
UITableViews are subclasses of UIScrollView (or at least conform to their behavior), but you really want to let the iPhone handle the selective drawing/cell reuse for you that the UITableView provides.
You should use UITableView if it does everything you need.
However if your tableview cells are really complicated, or you want to enable paging on the scrollview, you should take a look at the PageContol sample code that Apple provides. In a nutshell, you watch for movement in scrollViewDidScroll: and load new "pages" just before they become visible. This method works very well in practice for arbitrarily long lists of pages.
I'm trying to avoid putting a button in my UITableViewCell subclass so that I don't unnecessarily lag up the scrolling speed.
The button would push another view onto the navigation stack.
I figured since UITableView already has built-in and optimized methods for managing this, that simply limiting the touchable area of my cells would be the easiest and most effective way of achieving my goal.
I really have no idea how I would implement something like this. I have a feeling I would have to override pointInside:withEvent: or hitTest:withEvent:, but I'm not sure how. Managing touchEvents and the UIResponder stuff still escapes me.
So my question is ultimately, in my rootViewController, how would I implement that selecting a row will only work at lets say 220,10,40,40 ?
Thanks!
A UITableViewCell should have a normal selection style(i.e. not UITableViewCellSelectionStyleNone), generally speaking. You shouldn't have buttons on cells that you are reusing an arbitrary number of times.
If you're using a lot of UIButtons in your UITableView, you may want to rethink how your UI is designed.
You can't easily (to my knowledge) change "selectable" parts of a cell - the whole cell must be selectable no matter what(you can set the style to no selection, but you'll still recieve touch updates).
The behavior you're describing sounds like a job for UITableViewCellAccessoryDetailDisclosureButton, actually. If you're going to be pushing another view onto the stack but don't want to do that when the user selects the cell proper, use a detail disclosure button to maximize your consistency with existing UI convention. It's hard to say without more information.
As for doing the work necessary to detect touches in a sub-region, that may be more trouble than it's worth. True, adding subviews to a cell incurs a compositing cost but if you're only talking about one button, and a button whose background you can set to opaque, you'll probably be just fine. The alternative is reinventing the wheel to recreate button behavior in a subregion of the cell and that doesn't sound like functionality that will be much fun to maintain as the SDK matures.
That said, adding views to a cell doesn't incur a compositing cost per se, it's drawing those views that's the trouble. So if you really wanted to go nuts on the optimization, you could create a pre-rendered cell background image that includes the appearance of a button you want and then place a custom, image-free, see-through UIButton instance right over top of it. Nothing to draw, so no additional compositing cost. Worth a shot.
You didn't come here for a premature optimization speech, so I won't bother with one, but I say just do the cell with a normal button for now, make sure you like how the functionality feels to use then optimize toward the end if you're looking at performance that you're not happy with.
I imagine this is pretty dead-simple, but somehow I haven’t been able to get it to work:
I need to display a View containing a group of controls (roughly 800px tall) -- which can be scrolled vertically by the user, as that view is too big to fit on the screen all at once.
That’s it.
I’d think that this might mean something like this:
UIView [normal size] > UIScrollView >
UIView [the oversized one]
... and then enabling vertical scrolling, etc.
But somehow I'm missing something, as the best I've gotten is the first screenful to appear on-screen, without the ability to scroll down.
~~~
[Note: I know that this might often be done using a Table view, and vertical scrolling then happens for ‘free’. But this is a series of special-purpose controls (an odd assortment of various UISliders, UISwitches, UILabels, UIButtons, etc.) that wouldn’t readily fit into a standard table view without a bunch of customizing anyway. They’re also static as well (i.e., don’t need to be changed programatically) -- hence they can be completely built in IB, and that’s how I’d much prefer to do it for this situation anyway. I just need to allow the whole lot to be accessible via scrolling.
I also know that they could be split up into multiple screens, and I'll do this if absolutely necessary; but they're a unified logical group, and so that's not the optimal choice in this instance.]
Any suggestions? That (and/or a code fragment) would be VERY much appreciated.
Many thanks in advance!
My initial thought is... have you tried:
[scrollView setContentSize:CGSizeMake( scrollWidth, scrollHeight)];
My secondary thought is the UIScrollView may not be receiving the scroll commands as you are really scrolling on a UIView, and not the UIScrollView directly... You might need to do some subClassing to get this operational, but I'm afraid that's a bit beyond me as I am still a beginner. :)
My tertiary thought is - why are you adding a UIView to the UIScrollView rather than adding the controls directly to the UIScrollView?