views:

142

answers:

3

Hi.

I'm new to Objective C, and to the iPhone and Mac development environments in general. I like the object model - it takes me back about 20 years to when I first started OO programming in the way that the object methodologies are implemented. Much of the basics seem to have been lost in the ensuing years, and to some extent, this is a much purer environment.

Learning the language and xCode is another story altogether though, and I don't yet have the hand of IB, and to be honest, I don't find it all that intuitive.

I'm in the process of creating an iPhone app, and I need to display data in a tableview. For the reasons noted above, I'm not using Interface Builder, and, so far I've created pretty much everything else by hand. For me, that's by far the best way of learning and understanding how everything hangs together.

But so far I've not seen very much in the way of examples of how to handcraft a UITableView object to place onto a view. Nothing usable, in any case. There's some discussion items within the Apple documentation, but it's not what I would anything like a practical working example.

Does anyone have any such examples, please?

Thanks in advance for any and all contributions

A: 

To create your own UITableView just instantiate the class, and add it to your viewController's view. (IB just does this for you). It's the same with any built in object that's a sub class of UIView.

UITableView *tableView = [[UTableView alloc]init];
[[self view] addSubview:tableView];

There's a lot of other things you'll need to do like set the frame property so it fills the view you're adding it too, and set the style and everything else.

Best bet is to read up on the Table View Programming Guide then look through the UITableView Class Reference

side note: You should really just use IB when you can. It saves a lot of headaches and time, and once you realize it's just saving you lines of code you have to maintain you will enjoy it!

Jessedc
Thank you; that has given me a great start. I'm now starting to try to get my data displayed. Stay tooned. :)The Table View Programming Guide was the documentation I had referred to in my original post. It's probably just me, but I really don't find that document to be all that clear or helpful. It's more of a reference than any sort of an example of how things may be done on a practical sense. Thanks again for your assistance.
Redback
+1  A: 

You are swimming upstream. Learn to use Interface Builder to make your life easier. Take a look at this tutorial and you should start to understand it a bit better:

iPhone Application Example

Also, I highly recommend Erica Sadun's iPhone Developer's Cookbook. The second edition should be available in December. Just buy it. You won't be sorry.

Matt Long
Hi Matt, and thank you.I am yet to be convinced that using IB will make things easier. :) I am a stubborn old fart, and I much prefer to hand code things, especially in the early learning phases of a new language. I like to get my hands dirty under the hood, and thus I find I gain a far greater understanding of what's actually happening.
Redback
This is also why I recommend Erica's book. She shows how to do things programatically as well. I will again caution you though, that the sooner you get past the stubbornness, the quicker you'll become much more productive. I used to be a Windows programmer. I tried to shoe-horn the Mac/iPhone way into the paradigm I already knew. That was a bad idea. Just a word to the wise and best regards. ;-)
Matt Long
Matt, I appreciate your honesty and experience. My background goes way back, beyond Windows, beyond DOS; I've worked on some big iron systems. I've also worked on Palm (going right back to V1 devices) and Windows CE (yeah, ok, Windoze Immobile) and again going way back to V1 devices. It's not so much a matter of shoehorning into the paradigm that I know, but more in terms of wanting - needing - to understand the language, its constructs, and how everything is represented programatically, and from that base I can then move to understand how the tools will work for me. Cheers.
Redback
Fair enough. I can relate to exactly what you mean, actually. Best regards.
Matt Long
+1  A: 

For an example of an application that creates all of its views programmatically, I can direct you to the source code of my application Molecules. It makes very little sense to manually create UITableViews, because you'll want to manage them via UITableViewControllers.

As Matt points out, using Interface Builder is probably the preferable way of doing this now. I originally wrote this application when Interface Builder was less capable than it is today. However, I have seen a very slight reduction in application startup time when using a view hierarchy entirely generated in code vs. one deserialized from a NIB.

Brad Larson
Brad,I've seen and downloaded your app in the past, and it's a truly great application. I've had a quick look through the code, and it is very comprehensive. I am sure that I am going to learn a lot from your work, but that's going to take me a day or three to just read and assimilate it all, let alone comprehend how it all hangs together.Thank you very much; your efforts are greatly appreciated.
Redback
Oh yes, one other thing, please. You said "It makes very little sense to manually create UITableViews, because you'll want to manage them via UITableViewControllers." Could you please elaborate on this for me a little? I am reading this a little bit differently from the other comments that suggest that I just use IB because it's there. You seem to be suggesting something a little different, and I would like to understand your further thoughts on this.
Redback
Cocoa is heavily reliant on the MVC design pattern. UITableViewController has been provided for you as a controller class for managing the logic around a table view, and it handles the table view creation and display for you. You'll find that Cocoa Touch is architected in such a way that it's cleaner to work with view controllers for full-screen views, rather than the views themselves.
Brad Larson
Thanks, Brad. I've seen some other references to the MVC paradigm, so that's clearly something that I need to read up on and understand.You say that using view controllers is cleaner than using views for full screen views. What about partial screen views, or instances where you might have more than one table view on the one window? In the app I'm building, the initial screen has a single full-screen table view. The next screen requires various datasets that need to be scrolled through, with a table for each dataset. I've used a dropdown for the dataset selection in the past. Suggestions?
Redback
I'd look at how Apple handles this within the applications they ship with the device. They never present multiple table views on screen at one time. In place of drop-down selections, they tend to use grouped table views that hold the current values of various settings. Tapping on that setting drills down into a fullscreen table holding all of the potential values for that setting.
Brad Larson