PDA

View Full Version : First time in Xcode, and stuck!




Nermal
Jun 3, 2012, 08:07 PM
Hi all,

I've been developing for Windows for years, using Visual Studio since its first release, and now I'm trying to make a simple Mac app in Xcode 4. However, I'm having great trouble with finding documentation. Lots of the beginner stuff is outdated (I've heard that earlier versions of Xcode are completely different), and most of what I've found for Xcode 4 expects you to already know your way around version 3.

I've tried to get started by myself but I've hit a wall, and can't help but think that I'm overlooking something simple. I've used the Cocoa Application template and have dropped a Button onto the window, but I can't figure out how to attach code to it.

In Visual Studio I'd just double-click the button (which would open the Click handler), but in Xcode that's only for changing the text. Right-clicking opens a black menu and one of the options is "performClick", is that what I want? It doesn't seem to do anything; I've clicked, right-clicked, double-clicked... and nothing happens. I get a little "+" in the circle when I hover over it, but clicking it does nothing.

I'm obviously missing something simple here. How do I attach code to the Click event? And does anyone know of any "Xcode 4 for Visual Studio users" documentation? I've found many articles on how to make certain parts of Xcode function more like VS, but I'm really after something more "beginner friendly" before I get into trying to customise it.

Thanks :)



lloyddean
Jun 3, 2012, 08:46 PM
<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.

Catfish_Man
Jun 3, 2012, 08:54 PM
Hi all,

I've been developing for Windows for years, using Visual Studio since its first release, and now I'm trying to make a simple Mac app in Xcode 4. However, I'm having great trouble with finding documentation. Lots of the beginner stuff is outdated (I've heard that earlier versions of Xcode are completely different), and most of what I've found for Xcode 4 expects you to already know your way around version 3.

I've tried to get started by myself but I've hit a wall, and can't help but think that I'm overlooking something simple. I've used the Cocoa Application template and have dropped a Button onto the window, but I can't figure out how to attach code to it.

In Visual Studio I'd just double-click the button (which would open the Click handler), but in Xcode that's only for changing the text. Right-clicking opens a black menu and one of the options is "performClick", is that what I want? It doesn't seem to do anything; I've clicked, right-clicked, double-clicked... and nothing happens. I get a little "+" in the circle when I hover over it, but clicking it does nothing.

I'm obviously missing something simple here. How do I attach code to the Click event? And does anyone know of any "Xcode 4 for Visual Studio users" documentation? I've found many articles on how to make certain parts of Xcode function more like VS, but I'm really after something more "beginner friendly" before I get into trying to customise it.

Thanks :)

'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.

Nermal
Jun 3, 2012, 09:55 PM
<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.

Thanks, unfortunately I'm struggling with that and just can't believe how bad this is. It doesn't help that the document contradicts itself (such as an instruction to not change any options followed by a screenshot with some of the options changed) but frankly after getting to the "Adding a Track Object" chapter while still not knowing why I'd done half of what's listed, I just closed Xcode and decided to rant on here instead :)

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.

It doesn't seem a bit clunkier, but rather a LOT clunkier. Maybe I've just been spoiled with Visual Studio but from what I've seen so far I just can't believe how people manage to put up with Xcode. From this experience, it honestly looks like I should just stick with Windows development.

Thanks for your help anyway, but this just seems to be far too different for me to get my head around. When I have more time I might approach it again from a "fresh slate" but at this point I just can't afford to relearn from scratch.

lloyddean
Jun 3, 2012, 10:51 PM
Welcome to the broader programming world!

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

Nermal
Jun 4, 2012, 12:27 AM
You will be pleased to know that I subsequently got a "hello world" app up and running - click the button and a textfield changes to "Hello World" :D

You will be less pleased to learn that I did it in C# through MonoDevelop :o

But the point is that I now have a system up and running that I'm (mostly) familiar with. Of course, I'll need to do some testing to see what works in Mono and what doesn't, but I'm feeling a lot better about it now!

Catfish_Man
Jun 4, 2012, 12:21 PM
Thanks for your help anyway, but this just seems to be far too different for me to get my head around. When I have more time I might approach it again from a "fresh slate" but at this point I just can't afford to relearn from scratch.

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. :)

mfram
Jun 4, 2012, 12:55 PM
Thanks for your help anyway, but this just seems to be far too different for me to get my head around. When I have more time I might approach it again from a "fresh slate" but at this point I just can't afford to relearn from scratch.

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? :rolleyes:

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.

Nermal
Jun 4, 2012, 02:38 PM
Using C#/MonoDevelop, I'm still having to learn bits of Cocoa. I've had to set up outlets and actions (and I think I know when to use each now) and I'm learning new property names, such as .StringValue instead of .Text. The key difference is that I understand my way around the language so it's not totally unfamiliar like yesterday's attempts. Once I'm used to how Cocoa works in Mono, it could end up being a stepping-stone to a "pure Apple" environment :)

knightlie
Jun 4, 2012, 04:51 PM
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.

themacster298
Jun 4, 2012, 08:25 PM
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.

displaced
Jun 6, 2012, 10:51 AM
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.

jared_kipe
Jun 6, 2012, 02:15 PM
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.


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.

Nermal
Jun 6, 2012, 04:19 PM
I went through the exact same experience as the original poster (albeit back with Xcode 2 or thereabouts!).

(etc)

Well, that gives me hope and I'll certainly take a good look once I can devote some time to it :)

Also, rereading my earlier posts, I apologise for the frustration showing through in my posts!

displaced
Jun 6, 2012, 05:23 PM
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'.

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!

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.

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.

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.

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

Well, that gives me hope and I'll certainly take a good look once I can devote some time to it :)

Also, rereading my earlier posts, I apologise for the frustration showing through in my posts!

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

jared_kipe
Jun 6, 2012, 05:59 PM
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.


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/

PatrickCocoa
Jun 6, 2012, 06:16 PM
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.

knightlie
Jun 7, 2012, 09:20 AM
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.

hatzinik
Jun 8, 2012, 02:30 AM
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!!!

Nermal
Jun 8, 2012, 03:12 AM
<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.

I have some time at the moment so I've been working though this. I've been taking it very slowly and have been sure to get an understanding of each concept as it comes up so that I know exactly what I'm doing.

Having said that, I've run into a minor issue.

On this page ( http://developer.apple.com/library/mac/#documentation/General/Conceptual/Mac101/Articles/04_Track.html), the first step is "In Xcode, in the project organizer select the Classes group folder."

Presumably it means the "Project navigator"; the list of files on the left. Is that correct or am I looking in the wrong place? The only Organiser I can find is a documentation viewer. However, even in the Project navigator there's no folder called "Classes". I used the TrackMix folder, but is that what I'm supposed to be doing? I just want to make sure that I'm putting the files into the preferred location :)

chown33
Jun 8, 2012, 10:22 AM
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

whooleytoo
Jun 8, 2012, 11:40 AM
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.


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...

ForkHandles
Jun 8, 2012, 12:05 PM
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

Nermal
Jun 8, 2012, 03:48 PM
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

Yes, of course I've searched, although I made an error in my previous post; although I did find the Projects button under Organiser, it still doesn't have a "Classes group folder" anywhere to be found.

ArtOfWarfare
Jun 8, 2012, 04:25 PM
Yes, of course I've searched, although I made an error in my previous post; although I did find the Projects button under Organiser, it still doesn't have a "Classes group folder" anywhere to be found.

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?

lloyddean
Jun 8, 2012, 04:36 PM
Yes, of course I've searched, although I made an error in my previous post; although I did find the Projects button under Organiser, it still doesn't have a "Classes group folder" anywhere to be found.

I'd say apparently in updating the guide for the latest version of Xcode they've missed some stuff.

The latest version of Xcode has defaulted to a different organization under the "Project Navigator".

Nermal
Jun 8, 2012, 04:51 PM
Ahh, that could explain it :)

I've used the feedback submission on that page so hopefully it'll be updated in the future. In the meantime, the app does work with the files just sitting in the TrackMix folder so I'll keep doing that in the meantime, at least while my projects are still small.

smith5646
Oct 16, 2012, 10:11 AM
I am also a .net developer and am just trying to get into the ipad world. After two days of frustration and a pile of pulled out hair on the floor, I am close to giving up. However, my ego is keeping me from doing so.

First, let me state that I understand that you can't compare windows to osx or anything that runs in either world. However, I have a few questions that might help change my learning curve.

1) Would it be more beneficial for me to learn with a text editor writing pure objC and doing everything the hard way and then shifting to XCode? I am used to studio doing work for me such as when I double clicking a button my the screen it opens the click event for me to put in my code. XCode is not as friendly (please don't jump on that wording) and it appears that I have to know where to put the code and what to type to do it.

2) Is there any type of terminology cross reference so I can google using the right terms? I'm after something like .net xxx object = objc yyy object. When I taught Java classes, I tried to explain how to use Java docs but told them the hard part was that you had to know what you were looking for. You can't find the spelling of the word phonetic but looking in the dictionary under F. Going back to question 1, I know it is a button click event in .net but what is it in objc? Having a cross reference that said .net click event = objc IBAction would be a huge start because then I can google IBAction.

whooleytoo
Oct 16, 2012, 10:53 AM
I am also a .net developer and am just trying to get into the ipad world. After two days of frustration and a pile of pulled out hair on the floor, I am close to giving up. However, my ego is keeping me from doing so.

First, let me state that I understand that you can't compare windows to osx or anything that runs in either world. However, I have a few questions that might help change my learning curve.

1) Would it be more beneficial for me to learn with a text editor writing pure objC and doing everything the hard way and then shifting to XCode? I am used to studio doing work for me such as when I double clicking a button my the screen it opens the click event for me to put in my code. XCode is not as friendly (please don't jump on that wording) and it appears that I have to know where to put the code and what to type to do it.

2) Is there any type of terminology cross reference so I can google using the right terms? I'm after something like .net xxx object = objc yyy object. When I taught Java classes, I tried to explain how to use Java docs but told them the hard part was that you had to know what you were looking for. You can't find the spelling of the word phonetic but looking in the dictionary under F. Going back to question 1, I know it is a button click event in .net but what is it in objc? Having a cross reference that said .net click event = objc IBAction would be a huge start because then I can google IBAction.

On the first question, I don't think using a text editor is a good idea. You lose all the formatting, code suggestions etc; I don't see any benefit in it. It might be a good idea to start in Xcode, but with an easier 'template'. You could for instance try creating a command-line app in Xcode, and use it to work on your understanding of basic Objective-C/Cocoa concepts, NSStrings, NSArrays, NSDictionaries, maybe NSNotifications and even Core Data. Then move onto a GUI app once you're comfortable with those. One nice thing about OS X/iOS development, there are a LOT of tutorials and forums out there to take you through the basics, if you have the patience.

On the second question, I don't know of any. I suppose the key terms:

IBAction - an instance method executed on certain events, such as a button click. These can be assigned programmatically or visually in the Interface Builder element of Xcode.

IBOutlet - an instance variable (pointer) to a GUI element or to an object (typically, as a delegate).

Delegate - an object which provides functionality for another object. For instance, in another dev environment you might subclass a view to customise it; but in Cocoa you use a generic view class, and customise it by making changes in the methods of the view's delegate. For instance, with most tableviews you'll have two delegates, one called "delegate" for handling user generated events (e.g. "the user double-clicked a row, what should I do?") and the other called "datasource" (e.g. "How many sections should I show?", "How many rows in this section?" etc.)

Protocols - There is no multiple-inheritance in Obj-C, I guess the loosest equivalent are protocols. If a class has a protocol, it's like a promise it'll implement the methods of that protocol. So the tableview's datasource delegate would implement the methods defined in the UITableViewDataSource protocol.

PatrickCocoa
Oct 16, 2012, 01:10 PM
I am also a .net developer and am just trying to get into the ipad world. After two days of frustration and a pile of pulled out hair on the floor, I am close to giving up. However, my ego is keeping me from doing so.

First, let me state that I understand that you can't compare windows to osx or anything that runs in either world. However, I have a few questions that might help change my learning curve.

As your second paragraph indicates, there is not a one-to-one correspondence between whatever knowledge you have now and programming for iPad.

This is one time where your existing knowledge is actively harmful to learning new things. That is a counterintuitive concept and you will be sorely tempted to keep trying to match up your existing concepts with Cocoa/OS X/iOS/Xcode concepts. The problem is that there are just enough matches between concepts to keep you doing this until you get frustrated and give up.

My advice is to mentally switch to "I know nothing" mode when you sit down to do iPad programming. What would a newcomer do? Run through a bunch of tutorials. Read some on-line introductions. Make some hello world apps. Celebrate your successes. Work through a big 400 page book.

These activities may seem like a waste of time, but they're not.

displaced
Oct 17, 2012, 04:58 AM
As your second paragraph indicates, there is not a one-to-one correspondence between whatever knowledge you have now and programming for iPad.

This is one time where your existing knowledge is actively harmful to learning new things. That is a counterintuitive concept and you will be sorely tempted to keep trying to match up your existing concepts with Cocoa/OS X/iOS/Xcode concepts. The problem is that there are just enough matches between concepts to keep you doing this until you get frustrated and give up.

Spot on. When I was learning French, words which sounded like English words but meant something totally different were called 'False Friends'. Same thing when moving between programming languages and paradigms.

Sure, IBActions feel a lot like .NET event handlers, but the context in which they sit is completely different.

.NET lets you tie code to the UI very tightly. Clever programmers have known that's a Bad Idea since about 1985. My .NET projects avoid (if at all possible) any direct linkage between the two. But I have to consciously make that architectural decision and code to that standard myself (and it can be quite laborious -- especially when it's soooo tempting just to slap a bit of logic in an event handler because it's so easy).

Cocoa won't have any of that. Cocoa says 'This is your UI. These are your Controller classes. Now, tell me explicitly how the two communicate.'

Also, find a tutorial on Cocoa Bindings and KVO. Pay particular attention to where UI object properties are bound to other UI objects and their properties. Keeping the View/Controller division encourages you to hook up many of your UI changes within the UI itself. So things like visibility of controls, populating values from sliders, etc. can all be done in IB without a line of code.

For example, think of a slider that has a range of 0 to 100. Now, maybe you want a label to show the current value of the slider. Just bind the text value of the label to the value of the slider (all in IB - no code!) and you're done. Now use an IBOutlet to make that value available in your code.

In Cocoa, think 'What data needs to move between my UI and my code, and what UI actions does my code need to know about?'

Ideally, your code shouldn't care about the UI. In a perfect world, you'd be able to remove the UI from an app and replace it with a script that could automatically push events and show data from your classes. Get that far and welcome to the world of automated testing ;)

EDIT: Sure, .NET has DataBindings, but they're nowhere near as sleek as Cocoa Bindings. They're much more 'hand-cranked' than Cocoa Bindings which 'just work' for well-written code.