I have a custom UITableViewCell completely written in code (no IB), it has an accessory button that simply calls didSelectRowAtIndexPath on the table view, and it works correctly and the method is called without problems.
However, when I tap on the cell itself (not on the accessory view) nothing being called, why ?
EDIT: the code is huge to put here ... however, the custom cell contains a ton of labels, couple images and scroll view ...
This is a shot in the dark, but if each cell has many different objects on it (i.e. images, labels, etc) then it may not be working because those objects are what the user is hitting when they try to click a cell. Does the cell turn blue (indicate selection) at all? If not, try hiding/removing those objects for now and see if it works.
If that is the case, then what you may want to do is create an invisible cell or button that sits on top of the other objects and calls didSelectRowAtIndexPath from behind the scenes.
This should solve your problem:
Raise selection event (didSelectRowAtIndexPath) when subview of UITableViewCell is tapped
Try setting your view's userInteractionEnabled property to NO.
This will make it ignore all touch events, and then the views under it will be able to catch these events. - Felipe Sabino
I'd partially answer my question: the wide scroll view is preventing the cell from calling didSelectRowAtIndexPath, removing the scrollView will solve the problem, however, I want to call this method with the existence of the scrollView ... anyone got ideas would be highly appreciated ...
You must post your code to understand what have you done...You have to check out this example to understand whether your code is correct or not...
http://www.edumobile.org/iphone/iphone-programming-tutorials/impliment-a-custom-accessory-view-for-your-uitableview-in-iphone/
Related
I was working with the grouped table view , and i wanted different controls for every row i.e switch control for 1st,radio button for 2nd ,checkbox for 3rd and so on.. how can this be implemented programmatically that is without using interface builder
thanks in advance
CharlieMezak said is right, you need to create in UIControls directly in cellForRowAtIndexPath , and add as subviews to contentView of the cell
For reference see the link below
http://www.e-string.com/content/custom-uitableviewcells-interface-builder
the link specifies the code to create cells programmatically as well as using IB.
Table View Programming Guide for iOS
Read the programing guide, and remember to use different CellIdentifier for each type of cell.
This is a pretty vague question.
Obviously you need to provide the cells to the tableview in its cellForRowAtIndexPath delegate/datasource method. So, either in that method or during the initialization of your view controller, build the UITableViewCell instances that you need, adding the various controls that you want to them as subviews and connecting the controls to your view controller so you can detect when they have been changed. Then just return the appropriate cell in the cellForRowAtIndexPath method.
Personally, I think it's a lot easier to use IB in cases like this. Just create an IBOutlet instance variable for each custom cell you want, and return the right cell in cellForRowAtIndexPath.
I've got an array of buttons in a UITableViewCell.
I populated them all through the cellForRowAtIndexPath method, but my tableview gets sluggish even though I have released everything.
Should I be using a custom UITableViewCell to populate?
Any suggestions on how to make this as smooth as possible for the user would be great.
Screenshot below.
You could create a custom cell / custom view pair for this specific cell, where you can draw all yours buttons in drawRect:. However, this would essentially draw all your buttons as an image so you wouldn't be able to tap them, but I guess you can always create a UITapGestureRecognizer to your cell (you'd still have to figure out which button was pressed by examining x,y values).
Still, I don't see any point in adding your tag buttons inside a UITableViewCell. You could come up for an alternate design in your UI, i.e. a UIView presented on top of the table, or a modal controller maybe.
I have a table view with different cells and basically I would like an edit button which would then make those red circle appear in each cell and be able to delete them. I already know how to make the "Edit" button appear and also I have overridden the commitEditingStyle method for the table view so I would like to know how to link the button to the action which trigers the red circle and how to make them appear and finally how to actually delete the cells thankyou :)
The editing style on your table view cells should be set to UITableViewCellEditingStyleDelete, and then you just need to make sure to call setEditing:animated: on your table view. UITableViewController can help provide a lot of this functionality pre-baked.
That's actually done through an undocumented API (though I'm not quite sure why) - using it would probably get your app rejected.
However, lots of apps simulate this functionality with their own code - you'd basically define a custom UITableViewCell subclass which changed its background color / toggled that extra red circle image when tapped, keep track of which cells had been tapped, and finally delete them all by calling deleteRowsAtIndexPaths: on the table with the collected list of rows.
This is really more of a curiosity than a hard coding question.
Both Facebook and Twitter both have a feature where swiping a UITableViewCell animates the cell off the side to reveal a drawer with more controls underneath. How is something like that accomplished?
Here is a great open-source method for doing exactly this, based on the behavior of the Twitter app:
https://github.com/thermogl/TISwipeableTableView
This is a problem I have tried a couple of different solutions to. I really liked the behavior of Mailbox (mailboxapp.com). So I set out to achieve this. In the end I ended up with what I believe is a very simple solution: use a UIScrollView inside your cell. I have blog post that discusses and a sample app that demonstrates this behavior.
2 ways to detect swipt action
look at the willTransitionToState: method of UITableViewCell.
this method will be invoked when you swipe at the cell.
Custom swipe detection in a TableViewCell
and then you can change your cell view easily.
You could just implement -tableView:willBeginEditingRowAtIndexPath: in your table view delegate.
From the doc,
This method is called when the user swipes horizontally across a row; ... This method gives the delegate an opportunity to adjust the application's user interface to editing mode.
As a UITableViewCell is just a UIView, you can use this fact to basically do anything you like with it.
To solve your problem, I'd attach a UISwipeGestureRecognizer to detect the swipe and then animate the view to a different state.
For example, you could create a custom cell that has it's content view laying above the "actions view". Whenever there is a swipe, you use a UIView animation to move the content view aside and show the action view with a couple of buttons instead. In a custom UITableViewCell you could add a delegate protocol to have the pressed action and the cell being sent to the delegate, i.e. your controller. There you'd trigger what ever there is to trigger and then transition the cell out of the state.
I'm trying to better understand how UITableView and UITableViewCell work, and one part of that is touch handling.
So when I touch a row on a table view, what exactly happens? My basic understanding is:
UITableView is a UIScrollView, so first it checks if it's a touch or a scroll
If it's not a scroll then the touch gets analyzed to see which row is under the touchpoint
It gets the cell at this indexPath (how?) and tells it to setHighLighted, setSeletected
Is that it? Does anybody have a more thorough understanding of it than that?
Probably somethign along the lines you mentioned, you never know though until you see t he source, why do you want to know anyway? you making your own tableview?
One last step is that the touch gets passed to the cells content view. That way any subviews in the cell will receive touch events. I'm pretty sure this comes after your step 3 and actions from cell selection will be processed first.