Don’t use UITableViewController. Really.
I was hesitant to even begin writing this blogpost for two reasons. First of all, I knew it would be short. More importantly, though, it’s because I know some people swear by the opposite. However, I must insist that you should never use a UITableViewController in your iPhone applications.
Let’s go over the reasons to use a UITableViewController.
- It’s a subclass of UIViewController, so it’s simple to use.
- UITableViews must have a delegate and a datasource. UITableViewControllers automatically conform to the requisite protocols. The file template even comes with the necessary methods included.
Really, when you think about them, both of those two points are non issues. If UITableViewController is a subclass of UIViewController, why not just use a UIViewController with a UITableView on top of it? Also, conforming to to the delegate and datasource protocols is as simple as adding
Let’s now cover a few reasons why you won’t want to use a UITableViewController.
Localizing your iPhone OS applications in Xcode.
Localization from within Xcode is a little unnatural at first. And to tell you the truth, I still don’t like it is handled. But that’s neither here nor there. This post will show you how to add support for localization within your own application.
Localizing
The first thing you need to do is localize your application into your native language. To do that, you must first create a Localizable.strings file. What you will do is select “New File…” from Xcode’s dropdown menu. Highlight the “Other” menu and select “Strings File.” Name this file “Localizable.strings.”
Getting to know Xcode/Interface Buider: PART III
This tutorial is an extension of http://www.skylarcantu.com/blog/2009/08/10/getting-to-know-xcodeinterface-buider-parts-i-ii-uitabbar-projects/. To get the most out of this tutorial, please either follow the linked tutorial, or download the sample project from the first post of the linked tutorial.
So, we have this beautiful tabbed project, built up in Interface Builder, and all is looking pretty good. But now, you want to do something with it. So let’s add a button and a label to our project. We’ll start by opening up Xcode and opening our FirstViewController.h. We will be adding a few variables here. A UIButton object, a UILabel object, and an integer called ‘count.’ Once those are added, we’ll set the two objects as properties of our FirstViewController. Make sure to preface the objects with IBOutlets, else Interface Builder will ignore the objects. Properties allow other objects to refer to the variables directly by referring to them within the object that contains them. Specifically, anObject.property. And finally, let’s create a method for what to do when our button is pressed. When completed, your finished FirstViewController.h file should look like this:
Getting to know Xcode/Interface Buider: PARTS I & II: UITabBar projects
Alright, it seems that a lot of you are missing a few steps when it comes to connecting together Xcode and Interface Builder. Hopefully, this will help you see things a little clearer, and see how things work a little better. This tutorial will show you how to create a simple UITabBar based application whose tabs are loaded from separate nib files.
The first thing you’re going to want to do is open a new project. Select a “Tab Based Application” and call it “CountAppula.” Be forewarned, when you submit an application to the AppStore, you can’t have any spaces in the name. You can change the display name in the Info plist to display “Count Appula” if you feel so inclined.
Read more