I read this great article from Twitter about fast scrolling and how to draw cells. I have implemented this fine, but now the hard part - the links in the tweet. Is there any way to use this approach and draw links in the cell as well? I know this is possible using a number of different label extensions, but the article specifically mentions not using UILabels and UIImageViews. If I have to use UILabels to achieve this that's fine. I just want to be sure this is the only way. Thanks.
Because detection of touch events is done in UIViews, one method might be to override the UITapGestureRecognizer on the UITableViewCell, and in the action it fires upon a touch, check to see if the tap is within the bounds of your link that was drawn. If it was, handle it accordingly, if not, handle it as a cell selection.
If you don't need cell selection, you could always have selection of a table cell perform the action you want for the link as well.
Related
Is there a simple way or methods for allowing touches to be handled in sections(headings) and to track which section(heading) was touched?
I only want to draw the cells for a section when the user presses that section. But i want all the sections to always be visible.
I know i can hack that by make the headings be represented as cells and then draw extra cells below that cell when its touched. But its kinda hacky i guess.
Thanks,
Code
An easy way is to provide a custom section header view for your table view that contains some control, like a button, that can handle those touches for you.
Take a look at UITableViewDelegate's viewForHeaderInSection: method. You can use the section number that comes from that method to identify which section of cells to reveal as the user touches a button in that section header view.
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've started implementing a UIScrollView that will contain many thumbnail-sized pictures and will scroll only horizontally. For this, I keep a limited number of UIImageViews created and remove/add them to the UIScrollView as the user scrolls it.
The problem is I need to find a way to optimize it as scrolling sometimes gets sluggish. Maybe it's the adding/removing from the view, I don't know.
I figure this is a common component that might have been implemented more than once, but I couldn't find any library that featured something like this. If there is something ready available, I wouldn't need to spend many hours fine tuning or figuring out how to improve my component.
This is different from the question that has been asked here many times: I don't want it to behave like the photos app. I want many pictures to be visible at a time and to scroll them smoothly, without "hard pages".
So, anyone know of a component which does something similar to this?
I managed to do something similar by using a rotated UITableView instead:
UITableView *tableView = [[UITableView alloc] initWithFrame:...];
tableView.transform = CGAffineTransformMakeRotation( -M_PI/2 );
You can then configure your UITableViewCells to display the images. You can also rotate the UITableViewCell contentsView.
I made a two dimensional scrolling component called DTGridView. You can use it with just the one row to make a purely horizontal scroll view. It has an API much like UITableView, where you have a dataSource and a delegate to tell it how many rows/columns etc and to handle touch events for the cells.
It also uses a method of cell reuse like UITableView does to save on memory. If you aren't using cell reuse on table views, you should be. :)
I would like to have formatted, clickable text and images inside a selected UITableViewCell. An example of the functionality I'm looking for can be seen in the iPhone Twitterrific app. When the user clicks on a cell, the cell is highlighted and the various links become highlighted and clickable.
I've seen the idea of using a UIWebView inside a UITableViewCell to handle formatting, but I'm unsure about this. Does that mean that every cell has to have it's own web view? I'm wondering about the expense and performance of such a method. Is there another way to get this functionality using Core Graphics?
I'm using custom drawing currently to draw my table view cells as described in atebit's blog post on fast scrolling.
Craig Hockenberry, author of Twitterrific, blogged about how he did that back in 2008:
http://furbo.org/2008/10/07/fancy-uilabels/
Basically, when the row is selected, he overlays UIButtons where the links are. It's imperfect, as sometimes the button won't fit in the same place the text does.
The first thing I would do is to checkout twitterific's old source code. And see if that version does what you are looking for.
I'm not sure how Hockenberry does it, but generally UIWebviews + UITableViewCells != fast scrolling.
My guess is that each cell does NOT contain a UIWebview until you click in it, when he quickly places a UIWebview in the cell to handle the text formatting. You then have a reusable UIWebview instance that you reuse but just change the content of repeatedly.
I have a problem, I can't solve properly.
In short: I want to create a single view (say: UIImageView) out of multiple subviews - i.e. it consists out of multiple ImageViews and TextViews. The thing is, I want to sort of 'render' them to be a single View.
Say, I take an image, add some description below, add a title above, and maybe another little image at the bottom. I want this whole thing to be a single UIImage to make it sort of 'listen' to one (e.g.) swiping gesture, which I cant tell to bring the new image to display.
Does anyone know the best way to achieve this? So far my results were fairly poor.
Any hints are welcome!
This is definitely possible. You seem to know about views and subviews, but should also read up on the "UIResponder" class and the "responder chain". The master view that you want to contain them all won't be a UIImageView, though, because that exists to just show an image. You can make all the ones you talk about subviews (addSubview: or in Interface Builder) of a plain UIView that you subclass yourself (say, MyContainerView), which then itself handles the gestures. If you want to take advantage of free scrolling on swipe, you could instead put your container view into a UIScrollView, which has its own set of semantics that you can leverage. For this latter, you should check out Apple's sample code for scroll views (don't have a link handy but should be easy to find) which embeds multiple image views in a scroll view.