Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS Welcome to Xcode 3

T

thefil

macrumors newbie
Original poster
Jun 11, 2007
27
0
As a computer science student, after reading the in-depth analysis of Leopard's retail release, the thing I was most excited about was the prospect of Xcode 3 and working with a unified interface for Mac (as opposed to the Java I've been using till now). Unfortunately, it appears Xcode 3.0 is a dramatic departure from 2.2; having visited multiple tutorial webpages, and Apple's own "Introduction to Xcode" articles given on the splash screen of Xcode 3, I can't manage to find enough that matches up to try anything. In other words, all these old tutorials are seemingly now inapplicable to Xcode 3, especially for someone who has never used the IDE before.

What I'm looking for is the following:
- an introduction to Objective-C 2.0, intended for either new or experienced programs, that includes information on variables, if structures, loops, etcetera. Syntax, basically.
- Using Interface Builder with Xcode 3 and how to interact with the GUI
- Core Animation

Any help would be much appreciated, at least until Apple gets into gear replacing their outdated help files...

*edit* An especially important thing that would help me is Objective-C's print to console command; at least then I could blindly make my way through it :p

Also, could somebody explain to me why classes in Obj-C come in two parts?
 
I've been reading "Cocoa Programming for Mac OS X" and although Xcode itself isn't much different, Interface Builder is totally different and I keep getting totally stuck. :( :(
 
Objective-C is a strict superset of C, so you can of course use printf() just like you would in C. However, more commonly you'd use the function NSLog() like so:

NSLog(@"Hello! This is an integer: %i, this is an object: %@", anInteger, anObject);

NSLog() essentially works just like printf (same string format) except that it takes an ObjC string constant (string in quotes with an '@' at the beginning) and you can print arbitrary objects using the %@ placeholder. Objects to be displayed are sent a message calling the "description" method and the return value of this method is what gets inserted in place of the %@". Built in objects generally have a reasonable description method already, and you can (and should) add one to any classes you create in order to make it easy to print information about them using NSLog().

Classes in ObjC come in two parts just because. One is the "interface" or declaration and normally goes in a .h file, the other part is the "implementation" or definition and normally goes in a .m file. That's just how it is.

FWIW, Objective-C 2.0 does not invalidate any Objective-C 1.0 syntax. That is, any Objective-C 1.0 code is valid Objective-C 2.0 code. Objective-C essentially just adds syntactic niceties with the major exception of garbage collection which is probably the biggest new feature. Garbage collection is optional and when turned on will work even for code that is written in strict ObjC 1.0. In this case, release, retain, etc will just be ignored. So in summary, you can start by just learning Objective-C 1.0 as really the changes in Objective-C 2.0 are not that significant, at least not to someone just starting out.

Disclaimer: I haven't actually had the chance to play with Objective-C 2.0 yet as I have to maintain Tiger compatibility in my two current apps, and haven't started on any new, Leopard-only apps yet. So none of this is guaranteed correct, it's just based on what I've read. I am using XCode 3.0 and IB 3, but I'm having to do some feeling around especially in IB 3, because it is quite different from IB 2. So far, I like the changes I see, at least after I figure out how to do things in the new way.
 
REBELinBLUE said:
I've been reading "Cocoa Programming for Mac OS X" and although Xcode itself isn't much different, Interface Builder is totally different and I keep getting totally stuck. :( :(
Click to expand...

Too true, I'm lost in Interface Builder; can't even change a Window title.
 
I like Interface Builder and XCode 3.0, XCode is just nice but Interface Builder is taking some time to get used to, I think its a change for the better though, I'm sure they'll be new books for Xcode 3.0 soon.
 
To the OP.

Read either the PDF or HTML version of 'The Objective-C 2 Programming Language.' It's included in the documentation for XCode 3 when you install. They also have the original document for Objective-C if you have not done that.

For IB 3. It is very nice. It isn't difficult to use, but it does have some weird usability issues.

There seems to be two opposing ways of doing the same task and developers seem to be split 50-50. The first is to create a simple class in XCode that will automatically become a descendent of NSObject. The next thing to do is open mainmenu.nib and drag this header into IB 3. From their add an NSObject instance into your interface. Change the custom class to your class, and then use IB to add outlets and actions. From their, write the files into the project, by default IB 3 doesn't seem to know where the project is and you have to physically select it. Next go back into XCode and do your work there. Of course when you save the files into the project IB will complain that they already exist so you need to either merge or replace, in this instance it is safe to replace.

The second way is to create the classes in XCode 3 and add the outlets and actions by hand in XCode 3, then drag the header across, change the custom class of the NSObject to this class and IB 3 automatically loads the outlets.

I just wish from a usability POV that Apple chose one way of doing this. It seems slightly unfinished, as if when they went GM the dev team were still trying to find a way of doing this efficiently.

I suppose it goes with the Next guys mentaility of having to enforce MVC in IB and XCode. It's nice, but when you look at other GUI kits and platforms, no-one else enforces it at a physical level. They let you mix and match code with GUI logic, a crap way of doing things yes, but it makes it very easy to move to a more structured way.

Maybe they will fix in this in XCode 3.1
 
XCode is fine, I've slipped into that with ease.

But...
IB looks great but for me it's a nightmare as it will no doubt be for any other users of the previous versions of IB

A question for anyone who might know the answer, today was the first time I built a new interface from scratch using the new IB, now all went okay (with a few hiccups trying to find the "new" ways)
But one thing I'm still yet to discover;

I create myself a new Object and load it with various Outputs and Actions, now what I cannot figure out is how do I create and implement the *.h and *.c files !!!!
 
thefil said:
What I'm looking for is the following:
- an introduction to Objective-C 2.0, intended for either new or experienced programs, that includes information on variables, if structures, loops, etcetera. Syntax, basically.
- Using Interface Builder with Xcode 3 and how to interact with the GUI
- Core Animation

Any help would be much appreciated, at least until Apple gets into gear replacing their outdated help files...

*edit* An especially important thing that would help me is Objective-C's print to console command; at least then I could blindly make my way through it :p

Also, could somebody explain to me why classes in Obj-C come in two parts?
Click to expand...

Well you're in a tough spot. The best way to learn is to get a book, but I don't know if there are any books specifically for XCode3 yet...still in addition to learning Obj-C and Interface Builder, you really need to learn Cocoa as well.

Core animation turns out to be pretty easy (or so I hear) once you've got firm knowledge of those three things.

I believe there's a command called NSLog to write to the console. It takes a specially formatted string, so either use an NSString object, or if you're using a constant string, try this:

NSLog(@"hello world");

It's been a while since I did Cocoa but it's actually a great toolchain/environment for building apps really quickly. There's a lot of "default" behavior there that means you spend more time actually creating useful features and less time worrying about standard details.

Finally, Obj-C classes are split into 2 parts for a very simple reason. One part is the declaration of the class; this contains the name of the class, and its public data members and public message handlers (functions, essentially). The other file contains the actual implementation for all of those message handlers as well as any private data structures.

The reason for this is that the first file acts like a header (if you were writing in C, you would always create a header file); when you want to use that class in another part of your program you just include the header file into that program file and now that file has access to the class structure.
 
The new version of Interface builder, relies on the user implementing the functions instead of letting Interface builder do it for you. E.g.

Instead of making a function called: sumTableColumn:
you go into your header file and implement it
- (IBAction) sumTableColumn(id sender);

uh I may have that syntax wrong... I forgot my Objective-C OMG!!!

durr forgot: then when you go back into IB you'll be able to link that function to a button or whatever. I don't like it, but that's how apple implemented it... dunno why though....
 
I'm learning C++ using Xcode, and the upgrade totally threw me off. I'm spending more time learning how to use the new Xcode than I am learning C++. I'm sure I'll get used to it in time. Interface builder is a bit crazy for me though. I'll definitaly be keeping an eye out for a book on Xcode 3.
 
garethlewis2 said:
It's in my previous reply.
Click to expand...

My apologies garethkewis2, I have just noticed it now :rolleyes:

In fact I ended up using method 2 as I'd already created the nib file and I tell you what it's a very clumsy approach to setting up, first of all you end up manually editing the *.h file to correctly name the interface, then the *.c file's @implementation...

This is going to be pretty awkward I'd of thought for people just coming into Xcode.

Anyway thanks again, I seem to have it sorted out now
 
Reflections said:
This is going to be pretty awkward I'd of thought for people just coming into Xcode.
Click to expand...

The new way is actually less awkward overall. Now you can add/remove outlets and actions to your header file in Xcode and IB will automatically sync the NIB. This makes it much easier to incrementally design/implement your UI. Before you'd have to re-import the header into IB manually.

The old way, on the other hand, made it easier to initially create your UI classes, but keeping subsequent changes in-sync was more of a pain.
 
@Alloye
I suppose it will be okay if you have never used the "old" methods, it's just I'm a bit of an old dog now and new tricks don't seem to work for me ;)

I have blended in quite well to XCode mind, in fact I'm impressed with XCode itself, I suppose IB will become second nature sooner or later but I think I'll have to take a new approach to building the GUI from now on as my old ways will most certainly conflict with this version of IB

All in all though well done Apple...
 
I've got to come down on the "way, way better" side of this debate. XCode has always been, and remains, one of the most incoherent development environments I've ever seen, but generating some of your code from inside a separate interface design tool was an astonishingly random architectural choice and I'm glad they fixed it. Design interfaces in the interface tool; write code in the code tool. Simple.

Just to reveal my biases, of course, if there's one thing Microsoft has done right ever, it's Visual Studio. It spoils you for other development environments. Some would say in a bad way, but I suspect those people simply enjoy pain.

I keep meaning to see if I can get a good workflow going using TextMate projects instead of XCode for my primary editor in Macland, but I haven't gotten around to it.
 
Gelfin said:
Just to reveal my biases, of course, if there's one thing Microsoft has done right ever, it's Visual Studio. It spoils you for other development environments. Some would say in a bad way, but I suspect those people simply enjoy pain.
Click to expand...

I use Visual Studio professionally, and I agree it has some nice features that Xcode doesn't. It's also great environment if you like really tight integration between tools.

That being said, I much prefer working in Xcode. The biggest problem with VS is that it encourages a poor design pattern that makes it difficult to adopt MVC. I also think the whole idea of using generated code for UI creation is utter garbage. I can't tell you how many times I've managed to get the code view and design view out-of-sync. I'll take Interface Builder's approach of creating a serialized object graph any day. (To be fair, WPF/XAML does address these issues to a degree if you're writing .NET 3.0 applications.)

As for my biases, I love Cocoa and tolerate .NET. YMMV. :)
 
I've been using XCode 3.0 for some days now, and I think that it does need some polishing.

1) Some stability issues need to be fixed. Especially for XCode.
2) The run log does not appear by default. Why?
3) The build and run button no longer has a keyboard shortcut. Why?
4) IB: It certainly needs some polishing. When selecting an item in a window, it is very possible to select the cell. But you may not want that. It is also very difficult to select an NSView inside a Scroll View (to resize it, for example) without having to try one or two times. It always selects a cell, or the scroll view. Finding new stuff is also difficult.
4)When I create a class inside IB, when I try to create the class files, it no longer automatically points to the project in XCode whose .nib file I have open. I need to follow the path to the project in the finder. Why?

On the bright side: XCode 3.0 and IB look better, feel better, smoother and more reliable. XCode's automatic .nib synchronization is neat and very relaxing. The search function for Cocoa interface elements is also very good, and XCode's little visual enhancements (like when you point your mouse at the left of the editor's window, it will highlight the current branch you are pointing your mouse in).

I haven't been involved with OBJC 2.0 yet. Although ObjC 1.0 code can be compiled with ObjC 2.0, I don't know if new ObjC 2.0 style code can be run on pre-Leopard machines. I think I will just sit this one out for the time being, at least when Apple's documentation is updated. Same goes with Core Animation. Cool features, but I will adopt them later.

Overall, I think that the new XCode is a huge step forward, but it suffers some illnesses that plague most of the new products in their infant stages. I am sure that XCode 3.1 will address most, if not all the issues anyone has.
 
Soulstorm said:
2) The run log does not appear by default. Why?
Click to expand...

In Xcode Preferences, open the Debugging tab and change the option for On Start from Do Nothing to Show Console.

Soulstorm said:
3) The build and run button no longer has a keyboard shortcut. Why?
Click to expand...

:confused: Command-R works for me.

Soulstorm said:
4)When I create a class inside IB, when I try to create the class files, it no longer automatically points to the project in XCode whose .nib file I have open. I need to follow the path to the project in the finder. Why?
Click to expand...

This might help. In a nutshell, the preferred workflow has changed.
 
I've noticed that Xcode text input is really slow on my G4 1.5 GHz, sometimes even just 2 or 3 characters per seconds appear when typing.
 
Sijmen said:
I've noticed that Xcode text input is really slow on my G4 1.5 GHz, sometimes even just 2 or 3 characters per seconds appear when typing.
Click to expand...

Check to see if Spotlight is indexing, if not open Activity Monitor and see what's taking all your CPU power. When I used XCode with the Earlier versions of Tiger it was like that for me, it was the Finder problem that everyone was getting where it would use all the CPU for what it was doing, no one really knows. If you have to relaunch finder, but I suspect its Spotlight Indexing. I'm on a G4 1.33GHz 1GB RAM and XCode runs fine for me.
 
Xcode 3 Applescript Studio Slowness Solution?

Sijmen said:
I've noticed that Xcode text input is really slow on my G4 1.5 GHz, sometimes even just 2 or 3 characters per seconds appear when typing.
Click to expand...

I have the same problem with an iMac G5 running Xcode 3 after uploading to Leopard (10.5.8). The CPU shot up to 100% whenever I was editing my code and it became unbearably slow to edit projects. I tried turning off Spotlight indexing in its Mac OS Preference pane, but that had no effect.

However, I went thru the Xcode Preferences and found that once I turned off the Indexing checkbox: "Enable for all project" under the Code Sense pane, then performance got back to what I expected. It still seems a bit slower than Xcode 2.5, but not by much.

BTW- I originally installed Xcode 3.1, which doesn't seem to have this performance problem, but it has an even worse problem where it immediately crashes whenever you put a script object in your Applescript code. That's a huge bug, but I've seen it reported elsewhere (and Apple has had a lot of time to fix it, but hasn't). So I was forced to downgrade to Xcode 3.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back