Wow, this is very interesting! Thanks for this bit of knowledge! Jeff
On Mon, Oct 24, 2011 at 10:54 PM, competent_tech < [email protected]> wrote: > After a too long and painful process, and with a lot of assistance from the > community, I have finally managed to get UITableView to behave more like a > grid that our users require to consume the information in our application. > > Because I did not find a single solution for all of our requirements and > because of a lot of disinformation out there (i.e. UITableView can't scroll > horizontally without being in a scroll view, you can't have multiple > columns, etc.) I wanted to share some of the general techniques that we > used > to implement this behavior. > > First, our general end-user requirements were to have a multi-column grid > that can scroll both horizontally and vertically with the column headers > always visible. In addition, it was a requirement, due to the large amount > of data that could be presented through these grids, to be as prudent as > possible with resource consumption. > > When a UITableView is embedded in a scroll view, this last item becomes a > major issue because this eliminates the native UITableView's process of > recycling cells. > > As it turns out, the solutions to all of these issues are relatively > straightforward, but not readily accessible. > > There are plenty of articles that describe how to create multi-column > UITableViews. > > However, none of them addressed cell reuse if you add your own labels to > create multiple columns. To find the labels associated with your columns in > a reused cell in order to change the text of the cell, give each label in a > given cell a unique tag (corresponding to the column number, for example), > then call the ViewWithTag method on the cell to retrieve the correct label > for the column you are working with (only if you are working with a reused > cell). > > In order to create a header that does not scroll, you need to use a custom > view in the UITableViewSource's GetViewForHeader method. To ensure it does > not scroll, the view needs to have ClipToBounds set to false. > > If you try to use a gradient in the header, you will most likely be > unsuccessful because it is always clipped when scrolled horizontally. > Instead, use a standard background color and it should be displayed > correctly. > > In order to support horizontal scrolling, both the header view and the > individual row cells must have a frame width that is the sum of the widths > of the individual columns. > > You must also set the UITableView's ContentSize after ReloadData(): the > width should be the width of the view/cell calculated above (or the > ContentSize.Width, whichever is greater) and the height should be the > current ContentSize height. This will support both horizontal and vertical > scrolling. > > Finally, when you scroll the new UITableView horizontally, you will most > likely notice that the row separator lines are clipped. I was able to > resolve this by creating a custom cell that inherits from UITableViewCell, > overriding the Draw method and, before calling the base implementation of > Draw, setting the frame size width to the sum of the column widths. This > custom cell is then used in place of the standard UITableViewCell in the > UITableViewSource GetCell override method. > > Hopefully these concepts will help someone with similar issues in the > future. > > > -- > View this message in context: > http://monotouch.2284126.n4.nabble.com/UITableView-as-multi-column-scrollable-grid-tips-tp3935447p3935447.html > Sent from the MonoTouch mailing list archive at Nabble.com. > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch >
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
