nib vs xib

Easy thing.....

• xib --> xml
• nib --> binary

That's it. I use version control, so xib is my choice. Xcode creates a nib out of the xib on compile time

IBOutlet / IBAction Definition

One of the most important concepts of Cocoa (at least to get us started) is the way that Cocoa combines UI and code.
In a Visual Studio project the code that generates the UI is in the same file as the coding itself. 

This is not the case in Cocoa. We have our code completely seperated from the UI, which 

resides in a NIB/XIB file (or several ones).
To get it connected we need to let the code know what interfaces we have and let the UI know what we are working with. We will do this by defining Outlets and Actions in our code, creating an “interface object” in the UI that will be the interface between code and UI and connect the UI elements to that interface.

So what are Outlets and Actions? 

Actions are events which the UI sends to the code when something happens. If you click on a button Cocoa will start the code that you have defined by

1. linking the button to an action of an “interface object”
2. calling the method of that action in the code

An Outlet is a link from code to UI. If you want to show or hide an UI element, if you want to get the text of a textfield or enable or disable an element (or a hundred other things) you have to define an outlet of that object in the sources and link that outlet through the “interface object” to the UI element. After that you can use the outlet just like any other variable in your coding.

So let’s get started: 

We’ll create a small app which has a window with a button. As soon as you hit the button, the window will be closed. Not very interesting, but good enough to show how this works.
First of all we will define the outlets. We will only need to call the window to close it, so we only need an outlet  IBOutlet NSWindow *myWindow; The strange thing for me was that we have two definitions for myWindow (IBOutlet and NSWindow)..... but I guess you get used to anything, and that is just the way it goes.
Further we need an action for the time the button gets pressed on the UI. 

-(IBAction)closeWindow:(id)sender;

 

All actions have the IBAction return code (which is the same as void) and the (id)sender as an argument.
Once we saved the file we can switch to the UI in the Interface Builder. Here we add a NSObject whichs Identity we will set to the class in which we added our outlets and actions. Then we create the UI by opening the Window object and dragging a button from the library (Command Shift L) to our window. Now we will set the link from the button to the action. To get this done we need to right click on the button and drag it on the newly created NSObject item. A new popup will appear listing all available actions. You should select the one that you have created. 

After that CTRL-click on the NSObject item. Again a popup will appear listing the outlets that the class has defined. Now we have to drag a line from the outlet (to be precise, from the box right of the outlet) to the window.

Ok, so now we have a class which takes care of the interaction between UI and code; we have our UI, which we attached to the outlets and actions that we defined. So now all what is missing is the code which will do whatever we want when the action gets triggered.
Switch to Xcode and go to the source file to create the method that you want to add. Between the @implementation and the @end enter the method: 

-(IBAction)closeWindow:(id)sender 

{ 

     [myWindow orderOut:sender]; 

} 

myWindow is the window of your application (which is a NSWindow instance). The method orderOut hides the window. That’s it!
This way you can also get/set the text of text fields ([textField stringValue]), enable/disable buttons([myButton setEnabled:YES/NO]) or whatever you want.

Objective-C

In a glance, Objective-C is C plus object orientation and other fun little things.

Now being used to Java and C# for the last couple of years, this of course means one thing that I personally forgot very happily... pointers. But let's take it step by step.

Files and Headers

An Objective-C file has the file ending ".m", the header file has the file ending ".h"

To include the header files into your coding (be it source or other header files) you'll have to write "#import " for global headers (e.g. Cocoa.h) or "#import "headername.h"" for your own local headers. Besides the name (import <-> include) this is pretty much as in C++ (at least how I remember it :-) )

So starting of with, you would include the framework header file in your header file and your header file in your source file.

How Headers are setup

A header file normally includes an import for other headers and a class definition. The class definition consists out of the class name, its deriving object, its variables and its methods.

A simple class definition could look like this:

@interface AppController : NSObject {

int x;

}

@end

Now this class definition would not do to much as it does not have any methods, but it would define a class named "AppController" being derived from NSObject with one integer variable called x.

The definition always starts with "@interface" and ends with "@end"

A method definition in Objective-C will be defined like this:

- (int) setX:(int)y;

This defines a method setX with a return value of type int. To call the method you'll need to pass a variable of type int which can be accessed by the name y. The "-" in front of the method declaration is not a typo, but tells you that this is a "regular" instance method. A global class method would be defined with a "+" instead (comparable with the "static" keyword of Java/C#). The method definition will not be inserted into the curly brackets but between their end and the "@end" so the new class definition would look like this:

@interface AppController : NSObject {

int x;

}

- (int) setX:(int)y;

@end

The source file

To finish off our example here we'll have a quick look at the corresponding source file:

#import "AppController.h"

@implementation AppController

-(int) setX:(int)y

{

//Magic happens here.....

x=y;

return x;

}

@end

This should not be to much of a suprise now. Pretty much straight forward besides the "@implementation" and "@end" commands which simply wrap up the class related coding.

Details on versioning

After the first steps in versioning I stumbled over some beginner's mistakes, I guess.

So let's walk through a quick project setup.

1. Create a project in Xcode somewhere on your disk (you'll delete it later anyways....)
2. Click on SCM in the Xcode menu, and then Repositories
3. After selecting your Repository (mine is called Local Subversion), select the folder/branch where you want the project to be stored at
4. Select Import in the toolbar
5. Select the folder where the previously created project is located at and hit Import
6. Xcode will tell you that the project got imported
7. Now close the project and delete it
8. Again go to the Repositores (step 2)
9. Now click Checkout in the toolbar (don't click export like I did the first time... this will lead to a non-versioned copy of the project)
10. Select the folder where you want the project to be stored at. This will be the working copy of the sources that you will work on.
11. Hit Checkout
12. Now you should have a copy on your desk. Next step is tell the project that it is a versioned project. Go to the project settings. On the very bottom of the properties page (in the General tab) you can now select the SCM repository. Select the repository that you would like to use.
13. If you want to you can change the build output to some other directory.
14. Afterwards you will see that the project file was modified as there is a capital "M" next to the project file (as long as you have selected the SCM preference by right clicking on the file listing)
15. Now you can commit those changes back to the repository by clicking on "Commit Entire Project" in the SCM menu.
16. That's it :-) 

First things first.... versioning

So before we get all into Objective-C or Cocoa I would like to setup Xcode to do versioning.

Why versioning?

First of all, versioning does not save you from making backups. Having said that, if you mess around with code a lot you will find yourself trying out stuff. Most of the times you will have to try things to get your app to do what you want to. Sooner or later it will happen that you will think "didn't this work the other day??"

I tried to save myself from such a thought over the years with making several backups including timestamps but let's face it... You always forget the important one and comparing different versions is a pain. Versioning is supposed to help you here, so let's try it out.

Which versioning system?

Xcode supports three systems (at least the dialog box tells me that it supports three): CVS, Subversion and Perforce. Perforce is AFAIK not for free, so we'll skip that one. Since CVS is pretty old and since I read somewhere that Subversion is somehow a better/newer CVS I wanted to give it a try.

Getting started

I tripped over this article on the developer pages of apple which gives a basic guidance to setting up Subversion with Xcode. The main issue with the article is that it focuses a real server (with a lot of people working on it). Now this usecase is the most interesting one when it comes down to sourcecode management (SCM) software in general, but right now I am only interested in getting versioning for myself (and only on my computer since I don't have a MacBook right now).

So when you read through the article you will probably see that svnserve is better for you then the Apache module, at least that is what I thought. So what I did is set up a repository as described in "Creating a Subversion Repository"(only creating it in my User directory instead of /Library), I skipped the Apache configuration and continued on "Using Subversion from Xcode". That chapter basically just tells you to set the project settings to have the build output put somewhere else (so that you do not checkin those files) and how to use the repository with Xcode.

Now I do not know what I did wrong, but the best that I could get is an authorizations error after manually starting the svnserve deamon (which is not necessary according to the documentation). I searched the apple pages and googled around a bit but didn't get to lucky on what to do next. Finally I found this page which tells me where the config file of Subversion is (actually it just tells me that there is a config file and what it's name is, but since we have spotlight...)

When I opened the config file I found an interesting note:

   ### This file controls the configuration of the svnserve daemon, if you

   ### use it to allow access to this repository.  (If you only allow

   ### access through http: and/or file: URLs, then this file is

   ### irrelevant.)

Ok, so if I can use file:/ instead of svn/svn+ssh or http I should be fine..... at least that was my guess. Happily it turned out that this guess wasn't so bad so without starting anything manually and without messing around with the authorizations to much I know have the following config:

scheme: file

Path:

That's it! Now all the versioning works fine.

Finally a blog......

No, this post will not contain a "First post" post.

Having said that, what's this about?

I bought myself another computer book two weeks ago to not completely forget what I once knew about programming at all. That book is about Cocoa and I somehow want to share the first days of experience in that area. I don't want to discuss any general programming stuff here, just a bit of Objective-C specific stuff (since this will be the kind of stuff which I will find strange not knowing that language) and of course a lot of Cocoa and Xcode related stuff.

Where I come from....

I've been a geek for over a decade and came across several programming languages including C/C++, PHP, Java and Python as well as SQL and some other stuff. I wouldn't say that I'm an expert in any of these languages and the fact is that I've probably already forgotten most of what I once knew about these languages.

Quo vadis?

Reflection and sharing..... let's rock'n'roll