I have a UITableView that in 'normal' mode, show a UITableViewCellAccessoryDisclosureIndicator meaning if the user taps the row, another list is showed, like HIG says:
"Disclosure indicator. When this
element is present, users know they
can tap anywhere in the row to see the
next level in the hierarchy or the
choices associated with the list item.
Use a disclosure indicator in a row
when selecting the row results in the
display of another list. Don’t use a
disclosure indicator to reveal
detailed information about the list
item; instead, use a detail disclosure
button for this purpose."
When the user tap the edit button in the top bar of the UITableView, I think I have to change the disclosure because if the user tap it, a view for changing the information of the current row is showed (see the bold line above), again, like HIG says:
"Detail disclosure button. Users tap
this element to see detailed
information about the list item. (Note
that you can use this element in views
other than table views, to reveal
additional details about something;
see “Detail Disclosure Buttons” for
more information.)
In a table view, use a detail
disclosure button in a row to display
details about the list item. Note that
the detail disclosure button, unlike
the disclosure indicator, can perform
an action that is separate from the
selection of the row. For example, in
Phone Favorites, tapping the row
initiates a call to the contact;
tapping the detail disclosure button
in the row reveals more information
about the contact."
Have I miss understood the HIG, or I really do have to change the disclosure style in edit mode of UITableView? If yes, how I can intercept the edit mode when the user taps the Edit button?
Thanks in advance.
you do not need to manually change the disclosure indicator as the user switches in and out of edit mode. You can control what is displayed in edit mode by setting the "editingAccessoryType" property for the table cell. You would usually set that up in the tableView:cellForRowAtIndexPath method along with the "accessoryType" property which sets the disclosure indicator for the normal (non-editing) state.
From the table view programming guide:
accessoryType and accessoryView—Allows you to set one of the standard accessory views (disclosure indicator or detail disclosure control) or a custom accessory view for a cell in normal (non-editing) mode. For a custom view, you may provide any UIView object, such as a slider, a switch, or a custom view.
editingAccessoryType and editingAccessoryView—Allows you to set one of the standard accessory views (disclosure indicator or detail disclosure control) or a custom accessory view for a cell in editing mode. For a custom view, you may provide any UIView object, such as a slider, a switch, or a custom view. (These properties were introduced in iPhone OS 3.0.)
Related
I'm quite short on space. My navigation bar is full. Ideally I'm looking for something below the navigation bar which once tapped will change the sort order of the rows in my uitableview.
I'm looking for options ?
One option is to add tableHeaderView to the table view with the buttons which trigger the sorting action. If your table view contains only one section you can add it as section header(better use tableHeaderView).
Adding UISegmentedControl with the segments(for different types of sorting) as the tableHeaderView is an elegant way.
One option (although much less discoverable than items on the navbar) would be to re-sort when components of the cell are tapped. For example, let's say the cell had a picture on the left of a user, a title and a score. As you tapped on each component of the cell, it would sort by that component. Repeated taps on the same cell component would toggle between ascending and descending. That has the downside of intercepting the cell tap and you would only drill in when tapping on an area of the cell that you're not sorting by.
You could create a really snazzy custom toolbar that appears by tapping a gear shaped button on the navigation bar. It could slide down from under the navigation bar and sit there right below it, and when you finish with it you could send it right back under the navigation bar, hidden.
The advantage of that is your app has a really cool custom toolbar, and all of your buttons are secreted away in a single organized toolbar - the disadvantage being that you actually have to invent one of these.
As I'm thinking about it though, if you have buttons that are navigation related taking up all the space - not ones that do stuff - then this probably won't work.
I have a scrollview which has several table views as sub views...
say that I have selected a cell in one of the sub views. Now when I select a cell from another view, the cell I selected previously should not be highlighted.
How do I do this? I know I can do this using the first responder, but I am not sure how to do it.
Would anyone be able to help me out in this?
Thanks
From the apple interface guidlines:
Always provide feedback when users select a list item. Users expect a table row to highlight briefly when they tap a selectable item in it. After tapping, users expect an immediate action to occur: Either a new view appears or the row displays a checkmark to indicate that the item has been selected or enabled.
In rare cases, a row might remain highlighted when secondary details or controls related to the row item are displayed in the same screen. However, this is not encouraged because it is difficult to display simultaneously a list of choices, a selected item, and related details or controls without creating an uncomfortably crowded layout.
I don't think apple will approve an app that leaves a row highlighted (I had an app reject for that very reason). You should perform an action and then immediately unhighlight it. In some rare cases you can leave it highlighted while showing a related view.
However, if you store the current cell you have selected, you can call -deselectRowAtIndexPath:animated: on the tableview to deselect a row.
My table view is set up such that pressing "edit" creates an insert row using UITableViewCellEditingStyleInsert. The cell reads "add new item" and has a green plus next to it.
When the user taps the green plus, a modal view controller pops up so they can add a new item. This is fine. But it only works if they press the green plus itself - not the "add new item" cell.
How can I make it so that pressing the cell itself will do the same as the green plus?
Thanks!
You can; you just have to handle the selection yourself. First set allowsSelectionDuringEditing = YES, as shown above, then in the delegate's didSelectRowAtIndexPath: method, check to see if the selected row is the last row (or whatever row has your plus icon). If it is, run the same code you do in the didCommitEditingStyle: method.
I think ,Not possible because the entire edit mode process of UITableView is controlled by iOS (done by private API's) not exposed to us. we do have delegated (UITableViewDelegate) functions but not sufficient to get your work done.
Although, we can show the selection on the table Cell while in edit mode.
#property(nonatomic) BOOL allowsSelectionDuringEditing
http://developer.apple.com/library/ios/#documentation/uikit/reference/UITableView_Class/Reference/Reference.html
In the Safari bookmarks manager on iPhone, the UITableView seems to have behaviour that isn't standard. I'm referring to this:
alt text http://cl.ly/b7f0faead6a8586d3470/content
In edit mode, the bookmark UITableViewCells have both a rearrange control and a UITableViewCellAccessoryDisclosureIndicator accessory view next to them. How do you get both? In my table views, when you go into edit mode to reveal the rearrange control, the control takes the place of the accessory view, it doesn't display both.
Use editingAccessoryType property of UITableViewCell.
I have a table view cell, which is acting like button, performing some action without additional user interface presentation, then it will update the same cell with results of action. What type of accessory would be appropriate for such cells?
I would like to know in which cases I should use the subject types.
If you are keeping the cell in place, without any navigation, but will update the contents of the cell I don't think you need any disclosure accessory there. The flash as the cell is selected and deselected - and of course the change in the cell's visible content - should be enough. It would be more misleading in my opinion to show a disclosure indicator, with its implications of navigation, and then to remain in place.