I am looking for a third party library that would allow me to use a UIScrollView with a UITableView mechanism, so it will have something like viewForRowAtIndexPath, numberOfRowsAtIndexPath.. reusing views. I know a UITableView is a subclass of UIScrollView, but I want to do more customization that will be kind of hard when using UITableView.
Since UITableViewCell is a subclass of UIView, you could use a custom UITableViewCell, adding your view as the UITableViewCell's subview. I am assuming that all your views are of the same size. (In the table view controller's init method, remember to set self.tableView.rowHeight to a value that will accommodate the heights of your views.)
See the Customizing Cells section of Apple's Table View Programming Guide for iOS for more info.
Related
I just need a suggestion to Implement tableView for the application.
According to reference image is this a collectionView used in tableView?
Actually I want to implement 4 views on the top of the tableView something like Reminder app of apple. Obviously not to copy design but I need 4 views within UITableView.
These 4 views are also scrollable as its the part of tableview.
I am confused in this how can I achieve this design image attached.
my main concern is 4 top views tile style.
Image
In your case you may better use tableHeaderView property of UITableView and set your "reminder" view as tableHeaderView:
self.tableView.tableHeaderView = myReminderView
If you need to implement it as a cell, for some reasons, just create a custom UITableViewCell subclass and add UICollectionView with all DataSources/Delegates implementations you need inside this cell class.
As I understand, there seem to be three ways of laying out a custom table view cell:
In Interface Builder.
In layoutSubviews.
In initWithStyle:reuseIdentifier:.
What's the difference between the second and third methods? Also, why not drawRect?
P.S. I'm following Chapter 9 of the book Pro iOS Table Views by Tim Duckett, where we're building custom UITableViewCells. The author shows how to lay out the cell in the same order as above, but I don't know whats the difference between the last two since they both do away with IB. I noticed, though, that the author simply sets the frames in layoutSubviews unlike in initWithStyle:reuseIdentifier: where properties concerning the look of a view are set (e.g., background image, background color, etc.).
You should create your cell subviews in
- initWithStyle: (UITableViewCellStyle) style reuseIdentifier: (NSString*) resueIdentifier
And layout them in layoutSubviews.
-initWithStyle:reuseIdentifier method will be called once at initialization, but you cell may have incorrect frame at this moment.
Thats why you need to layout it in layoutSubviews method, it's called when cell needs to update layout, for example, when autorotation occurs. So if you will layout subviews in this method, you will have valid cell's frame and correct subviews layout.
-[UIView layoutSubviews]
gives you much more control on the way a view is relayout (I suppose in your book example it is done in the table cell contentView).
When you use a NIB file what you do is simply to recreate in memory the view hierarchy with some properties set, but the nib has not the dynamic capability to relayout a cell (or it is limited to the spring/struct or auto-layout capabilities). If you don't use the NIB you must create this hierarchy programmatically.
Especially in a table view cell subclass, you can add to it many properties that could change the way the cell is relayout, e.g. showing a thumbnail image or not, display a certain label or not, and in such cases you probably you need the layoutSubviews method to update the cell layout taking into account all the possible layouts due to different properties values.
I want to create a scroll view filled with grid cell of irregular size.
The UITableView, inheriting the UIScrollView, alloc cells effectively.
I just want to do the same.
Of couse, it is possible to use UIScrollViewDelegate to detect scroll event. But that will hold the delegate property. I want to use the delegate property as it used to be. So I have to inherit the UIScrollView as the UITableView does.
The question is how to do that?
Which method should I override to get the scroll event?
If you only want to implement cells with arbitrary heights, then you could simply implement tableView:heightForRowAtIndexPath: and you can decide the height for each cell in your table.
You should watch the WWDC 2010 video for UIScrollView, which includes lots of information about how to lay out many views. https://developer.apple.com/videos/wwdc/2010/
You could also look at the PhotoScroller example code for how to tile many views.
I have a beginner iPhone project going. I have a TableView, which is just a listbox with a bunch of entries and a small UiView on the bottom. See the pic.
The problem is that the UiView essentially becomes part of the listbox and will only appear when I scroll down to the last item in the TableView.
I'd like the UiView to be anchored on the bottom and never move. I've looked all around the Interface Builder and can't find anything (though in its defence I am a total noob to iPhone dev). How do I accomplish a trick like this?
alt text http://www.sqleffects.com/mystuff/ibissue.jpg
Ok, what you need is a UIView, that contains
an UIView, which acts as the TableViewController and thus has to implement the UITableViewDelegate and UITableViewDataSource protocols (but it MUST NOT be derived from UITableViewController directly, since by doing so the UITableView will automatically take up the whole screen size (except toolbars, navbars and/or tabbars))
another UIView, the one you would like to place at the bottom
by doing so, you can create an UITableView in IB (not an UITableViewController!) and connect it with the UITableView property in your UIView (the one mentioned in 1.)
using this method it is possible to give the UITableView a fixed size (which you'll need to, to have room at the bottom for your second UIView)
To build off gabtub's answer, the UIView containing your table view and your bottom view doesn't need to implement the UITableViewDelegate and UITableViewDataSource methods.
Since it sounds like you're building with a view controller, I'd make your main view controller a subclass of UIViewController (instead of using UITableViewController). You could then add your UITableView and your UIView the the UIViewController's view instance.
I'd then make your UIViewController subclass implement the UITableViewDelegate and UITableViewDataSource protocols - you'll end up with something that looks similar (code-wise) to your old UITableViewController subclass, but it's view property will be the underlying UIView instead of UITableView instance (if you poke around in the debugger, you can see the [UITableViewController view] and [UITableViewController tableView] return the same object)
One of the advantages over gabtub's suggestion is it saves you from creating a one-off UIView subclass, since you've probably already got a one-off UIViewController subclass (or, previously had a one-off UITableViewController subclass).
The problem is probably, that right now, the UIView is a section footer view, and is therefore contained within the table view.
If you delete the UIView from the TableView, scale the TableView to make space for the UIView and a bit more and put your UIView where you want it, it probably will be added to the TableView's superview. You can then resize the TableView to the correct size.
The bottom line is this: if you create your project based on the Navigation template, you can't resize the UiTableView, period.
So to do what I want, I basically have to start from scratch and pick a View or Window based template and drop the UiTableView on it manually.
I'm looking to have two views which are part of a constituent set. Data in each view would be best represented in a UITableView. I'd like to then add a gesture to flicker the view off screen and have another similar view brought in, with a page indicator control. My fear is that UITableView intercepts touches and becomes the responder to any such 'flickering' which the UIView might be waiting for. This will directly impede on the usability of the application.
So my question to you usability/UI experts is, is putting a UITableView inside of UIPageControl a poor design choice?
A UITableView is a subclass of UIScrollView. The PageControl sample provided with the iPhone SDK explains nicely how to use a UIScrollView with UIPageControl. Any method which belongs to UIScrollViewDelegate will be called inside your view controller if the view controller implements UITableViewDelegate.
To achieve what you are trying to do, the best approach would be to use UITableView with UIPageControl as explained in the PageControl sample.
Hope that helps!