iQuit

When I first started out learning about the iPhone Mike recommended this book to me:

Cocoa Programming For MAC OS X (3rd Edition) by Aaron Hillegass

The actual order of what I read and did to learn about the iPhone SDK was:

• Watched all the introductory videos on the iPhone dev site.
• Read the Objective-C Programming Guide and made notes on the language.
• Messed around with code while beginning development of my Whose Turn Is It app.
• Read the book.
• Realized all the code I wrote for the Whose Turn Is It app was completely wrong.

I found the book extremely helpful when it came to understanding the relationship between Interface Builder and your code.  Without the book I have no idea how I would have figured out the inner workings of GUI design.  I’m sure there are PDFs on the iPhone dev site that I haven’t read yet that contain the same information as this book, but I doubt they’re written to teach like this book obviously is.  So yeah, get this thing and read it if you’re going to work on the iPhone.  The last few chapters don’t apply to iPhone stuff as much as OS X programming (they get very focused on desktop work), however if you’re going to make any utilities for games like level editors or art asset tweaking stuff then these chapters will pay off too.

I’ve been working on the screen for editing user names and group names in the Whose Turn Is It app, and having a bastard of a time trying to figure out how to get the keyboard to show up right away for entering or editing the name.  I wanted to get the screen to look like this:

When I designed the screen on paper I figured I’d just be able to plonk a keyboard control on the screen’s view in Interface Builder.  No such luck!  No, it’s actually very simple, but only through hunting and pecking in the documentation did I figure it out:

// Implement viewDidLoad to do additional setup after loading
// the view, typically from a nib.
- (void)viewDidLoad
{
[super viewDidLoad];
[[self textField] becomeFirstResponder];
}

Sending the text field the becomeFirstResponder message activates the keyboard right away (and gets the cursor flashing in the text field).

I’m very torn on what approach I should take on the iPhone SDK documentation.  So far I’m working on a “read information when immediate need arises” model, but this hurts.  It makes it very difficult to predict how long each task I am doing will take.  I would love to switch to actively reading the documentation in detail ahead of time.  I know this would make my life easier, because as I alluded to in previous posts on the iPhone when you do things the right way things just work and work smoothly.  When you go the wrong way then it’s very much the square peg in the round hole.

Argh the new interface to Perforce is so brutal and painful to use that I think Mike and I should maybe look at the other version control choices we have.  You can’t tell what you’re doing in P4V half the time.

Here’s what I learned while trying to add my “Whose Turn Is It?” app to our perforce depot hosted on Mike’s machine:

1. If you’ve already made a project, make sure it’s located inside your perforce depot folder structure (i.e. within Perforce’s view of your harddrive).
2. Clean your project (you don’t want to commit anything generated during the build process).
3. Read the XCode Source Management Guide so you have an idea what you’re about to do.  This will show you how to set up your repository which is pretty simple.
4. Follow these instructions for getting the perforce command line client (p4) working on your mac.  DON’T set the P4CHARSET variable in this file if your server is configured to operate in the default non-unicode mode, just have the environment.plist file ready for action.
5. Use the property list editor to set your P4PORT value.  To do that you will need to make it so finder can see hidden folders which I figured out how to do here.  Then you can drag the .MacOSX folder into the open dialog for property list editor and use it to get at your values.  P4PORT should have a value like this:  <server host>:<server port>
6. In XCode with your Repository configured you should see something that looks like the picture at the end of this post.  This shows that you’ve got the repository configured to point to the correct location of p4, and that the command line utility is successfully connecting to your perforce server.
7. Import your project’s folder in the Repository window.  This will take awhile if your perforce server is remote, so be patient.

Here’s what your perforce repository should look like when it’s working in the repository window:

I’ve discovered the hard way that all the documents provided by Apple that start with “Guide to …” should really be renamed “Read this before you even THINK of trying to …”

I’m trying to finish development of an application that lets you track who’s turn it is to pay for lunch (or movies or whatever).  I’m developing it mostly for Mike and I to get experience in the process of listing an app on the app store.  What should be a simple app though is turning into a forced boot camp in iPhone development.  Here’s the things I’ve learned so far:

1. The first thing you should do when developing an app is lay out screen for screen what you want it to look like.  Draw it with the iPhone GUI components, or better yet mock it up with photoshop using this.
2. Once you’ve got your GUI designed, build an object model for your classes and objects that feed into the GUI components.  Try to keep your objects as simple as possible, because without a doubt they will change and adapt as you learn what’s working and what’s not working for your GUI.
3. If a major part of your app relies on the functionality of a particular component (for example UINavigationController, or a UITableView) then for god’s sake read the guide for working with that component so that you’re working WITH the sdk, rather than against it.  Generally I’ve found that if you find yourself trying to cram a GUI element into your app and get it connected and doing the right thing then you’re likely doing it wrong.

I’ve definitely decided that once this app is done I’m going to dedicate some time each day to slowly read and learn in detail the inner workings of all these GUI components, because I’m certain that knowing how these things work at every level will help me to generate much higher quality applications at a faster pace.