First time in Xcode, and stuck!

<http://developer.apple.com/library/mac/#documentation/General/Conceptual/Mac101/Articles/00_Introduction.html>

Please go through the WHOLE document. It walks you through building a simple application using the current version Xcode.

 

'IBAction' is the search term you're looking for. You declare an IBAction in the @interface of one of the objects in your nib (typically a "controller" in the MVC parlance), then ctrl-drag from the button to that object and select the action in question.

This may seem a bit clunkier, but the separation is a quite intentional way to reduce coupling. XIB files aren't code, and don't compile down to code, which is different from the code-behind style of doing things. More fundamentally, the programming model is different, not just the IDE (i.e. Cocoa, not Xcode). There will be things you're used to that simply don't have equivalents in Cocoa, and vice versa.

 

Welcome to the broader programming world!

It's no longer just what you know but how well you adapt to change that matters.

 

Understood that you don't have the time right now, but it's important to recognize that it's not that you're "spoiled" by Visual Studio, it's that you don't understand Cocoa.

I would be similarly lost and frustrated were the situations reversed and I was trying to do Windows development.

 

I downloaded a trial copy of VS for Windows and was equally frustrated. Couldn't get it to do a single thing useful. How does anyone use that crap?

The fact is, XCode works just fine. It's just different. The Cocoa design paradigm has evolved from the days of NextSTEP in the early 1990s. Programming for Mac and iOS are new skills that you will have to learn if you want to use them. But don't try to think of it in terms of "how do I get it to work like Windows?" because that will just lead to frustration. They don't work like Windows.

 

In order to learn XCode and Cocoa you're going to need to stop comparing it to Visual Studio, otherwise you'll just keep getting more frustrated. Programming isn't about the IDE, it's about the language and the API. Everything you've done in Visual Studio and XCode can be done at the command-line with a text editor without even starting an IDE.

I find Visual Studio as frustrating as you're finding XCode, and I've been through Basic, Turbo Pascal, Delphi, Java, C# and Objective-C. Take a step back and start at first principals.

 

Watch these tutorials:

http://www.youtube.com/watch?v=1Xqn5IHbusA&feature=list_related&playnext=1&list=SP640F44F1C97BA581

They might not be the best in the world, but it teaches you the basics.

 

I went through the exact same experience as the original poster (albeit back with Xcode 2 or thereabouts!).

VS.NET development is my day-job. Specifically, .NETCF smart device development. Quite a while back, I wanted to start Mac development so fired up Xcode...

... and was utterly, profoundly lost.

But I was absolutely determined to figure this stuff out. My thinking was: "Look at these great apps using great abilities of OS X. Xcode/Cocoa/Objective-C must be good if that's what it can produce. The problem's not with them -- it's with me.".

So having stuck at it, I can really say it's worth it. I'm nowhere near as competent in ObjC/Cocoa as I am C#/VB/.Net Framework (hell, I can almost recite the .NET class hierarchy), but that'll come with time.

Undeniably XCode/Cocoa asks more of the developer than VS. VS will let you stick all your logic, objects, etc. in the same class as the form. It will not guide the structure of your program, nor will it do anything to prevent you writing with every anti-pattern under the sun. It'll let you tie your logic directly to the UI. It'll let you put data access code in button-press events. Heck, there's loads of sample code that shows exactly that.

But XCode/Cocoa has some expectations and some rules. The Model-View-Controller pattern is pretty intrinsic to OS X and Cocoa, and XCode's approach really pushes this. You're still free to do nasty things like mix model and controller code (and sometimes that's right), but the separation of the View from the rest of the application is pretty baked-in.

Although my Cocoa/Xcode skills are still pretty weak, I can hand-on-heart say that my Cocoa projects just feel cleaner than my VS stuff. Do anything non-trivial in Cocoa/Xcode and the logic behind it all rapidly becomes clear.

The first time you do anything with CoreData I guarantee you'll have a grin on your face. Also, NSString is insanely powerful (initWithContentsOfURL:, for example), even if it takes a while to get used to things like [myString isEqualToString:anotherString] instead of a straightforward '=='.

My best advice would be to get used to Objective-C, play with a trivial app just to get the concepts down, then think of an app you'd like to write and go for it. Be prepared for many false starts until things click into place.

 

While you are correct about not being able to write code/logic into view/nib files, there is nothing preventing you from doing the opposite. You can certainly build and display views 100% in 'code'.

I do agree with you about the projects feeling cleaner. Ive been into both big C#.NET programs and big Xcode/Cocoa projects and it is very easy to get lost and have a hard time navigating around those .NET projects.

EDIT: Also this might be more Windows related, but the Unicode compatibility seems poor. I had a bunch of problems with encoding problems and version control in a certain .NET project. Had to go so far as taking files out of windows, into MacOS and converting their character sets and moving them back.

 

Oh, absolutely. Also, I like the way that Xcode handles custom subclasses of UI objects. Write the code, drop the object on the view in Interface Builder, then just set its class name to your custom class. Bam!

Not to mention how slow VS gets when solutions grow. My current project at work is approx. 200,000 LOC across 15-or-so projects. Builds take a daft amount of time. And don't even mention deployment - debugging a Smart Device project on a physical device over ActiveSync requires Zen-like patience and a high tolerance for spates of random 'Connection to remote device lost' messages. Doing the same with an iOS device and Xcode is orders of magnitude faster and more robust.

Bleugh. Not run into that myself, but I can see how it'd happen!

Hehe. No problem. I only replied because I knew exactly what you meant

 

OMG don't get me started. The first time I ever saw VS I was in a conference call/screen sharing session with the lead programmer on the project and he was showing me how to duplicate a class/view to change some specifics and he goes to rebuild/compile and it took ages! I couldn't believe it, I was like "does VS not do incremental compiles in the background or something?", and he says "oh I think it does, this isn't so bad". Yeah right, while working on that project was the first time I got to experience this myself. http://xkcd.com/303/

 

Huge Mountain to Climb

To the original poster, you have a huge mountain to climb. The mountain is there not because the new Apple way is WORSE, the mountain is there because the new Apple way is DIFFERENT.

As several other posters have noted, it's those differences that cause the problem. To clarify, there are several sources of differences:

Operating system (OS X vs. Windows);
IDE (Xcode vs. Visual Studio);
Language (Objective-C vs. whatever you're using now);
API (Cocoa vs. the Windows APIs, whatever those are called).

You will have a multitude of problems with each of the above areas. For example, once you get the current IDE issue you're having (how to hook up a button) fixed, you'll immediately run into an API issue - you may need to use NSString to do something with some text, and you're not familiar with NSString or how to reference the documentation. Then you'll get that figured out after a few days and have some Objective-C issue - you may want to append some text to your text string, so you'll try something like Append(textstring, additionaltext) when Objective-C and Cocoa demand textstring = [textstring stringByAppendingString:addionaltext];

After having spent three or four frustrating days just trying to get a damn button working, you'll either give up or relax and enjoy the ride. Others have done it. You can too, if you want.

 

Again, you're making comparisons where none should be made. Don't compare apples with oranges, just learn how your new coding environment works. Forget how VS or Windows does it because that's no longer relevant.

 

I 've recently started programming in Xcode, after being in the Windows programming paradigm for many years. It is indeed very different. A new (for me) point of view.

Certainly, a good programming book (like Cocoa Programming for MAC OS X, by Aaron Hilleglass) will make the transition easier.

However, after only some code been written, the whole experience seems smoother and more structured. Exactly, as the whole MAC experience feels smoother and structured.

Don't give up!!! Learn a few things at a time. Study again and again, write code, and try to get in (some) deeper waters each time.

As far as i am concerned, there is no way back. Everything seems better now.
To mention, that I am a hobbyist programmer, and i don't expect to earn any money soon, although i certainly will be playing with the app store, once i have enough skills to make something worth posting to the store.

Good luck!!!

 

Do you see a Help menu in Xcode? Open the reference docs for Xcode itself, and search for keywords organizer or project organizer.

Or google search terms: xcode project organizer

 

Excellent post, my experience was much the same. Xcode does 'force' you (or at least, prod you with menace) into doing things in a structured, thoughtful way. That can mean there's a steeper learning curve with Xcode/Cocoa than with many other development environments, and it can mean some 'simple' tasks take longer than you'd expect; but the benefits are your application is better structured and more scalable as a result.

There still are quite a few things I dislike.. Xcode is very unstable for me. The Storyboard view is still a bit awkward to work with. Some things (like 'undoing' a segue) that you'd think would be a simple option for a button instead require creating an action and a protocol. Etc.. etc...

 

Hi Nermal

I too have just started working on projects in xCode, coming from a Flash AS3 background I have probably found things even more challenging as you can program with objects with worrying too much about MVC.

The best way I have found to start getting a handle on how the code works is to forgo a lot of built in functionality. The projects I have completed have been written entirely in code avoiding any inclusion of built in objects such as Buttons, NavigationControllers, ViewControllers, split views, table views etc etc.

By doing this I have avoided concepts which at first look appear to be confusing. If I want a button, I create a button, place it in my view and create a Handler for it. In this respect it works in a very similar way to Flash AS3 projects. The only downside is that the visual appearance sucks!! It has, however, given the breathing room to get used to syntax and operational requirements.

Now I can create games and apps which are similar in functionality to Flash I can move on to learning how to use inbuilt Big objects such as those found in a storyboard.

The Xcode interface itself is incredibly helpful, although daunting at first, I have found it to be very useful.

Best of luck

 

Im not at my computer right now so I can't be certain about this...

I think the "Classes group folder" was just the name of a group automatically set up by many different templates in Xcode 3.x... I feel like as of Xcode 4.x, the names of the groups automatically set up changed... Why not just expand all the groups on the left panel and look for whatever is supposed to be in that folder?