macOS First time in Xcode, and stuck!

[lloyddean]

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]

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]

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]

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]

Achieve your rebirth!

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]

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.