macOS Basic Objective-C Cocoa questions?

[cpuin]

Dear All,

I read 3 different books about Objective-C with Cocoa.Unfortnatley there are some things i really can't understand.I would be very thankful if some of you explain in brief:

- delegates!After all i read i still can't understand what they are?
- following MVC pattern, what we do: the Cocoa template creates project with files ProjectNameDelegate.As i can see we should start our code in applicationDidFinishLaunching {}

- is there any example in which we can see clearly model, view and controller and the role of Delegates?

- if we use MVC it shoud mean we can create working console app and than just add the View and the controller in order to make GUI app, right?

- when we use CoreData, we can create the model, which replace the class, but when we'll place the methods which we want to manipulate the Model data?

 

[jared_kipe]

Dear All,

I read 3 different books about Objective-C with Cocoa.Unfortnatley there are some things i really can't understand.I would be very thankful if some of you explain in brief:

- delegates!After all i read i still can't understand what they are?
- following MVC pattern, what we do: the Cocoa template creates project with files ProjectNameDelegate.As i can see we should start our code in applicationDidFinishLaunching {}

- is there any example in which we can see clearly model, view and controller and the role of Delegates?

The purpose of delegates is to couple two objects together to provide event or callback functionality. It is an abstraction and contract that is most powerful when you did not write one or more of the classes involved.

It makes it easy to replace functionality or output from one object simply by substituting its delegate object for another one. (Usually the original controlling object is a stock framework object like NSWindow)

Let's say that you write an object that is responsible for error logging. You might use a delegate object to actually store or present the information. Your logging object would call a methong like -logOutput: (NSString *) on its delegate object.

You could have a couple of different delegate classes that perform different behavior.
LogFileDelegate
LogConsoleDelegate
They could be switched out at compile or runtime or just be nil to provide different ways to provide the logging.

- if we use MVC it shoud mean we can create working console app and than just add the View and the controller in order to make GUI app, right?

Not exactly, but you could switch out either the view or the view and controller to provide console based functionality. Effectively the view controller and view would be classes related to text formatting and input gathering in a command line environment instead of GUI Cocoa environment.

- when we use CoreData, we can create the model, which replace the class, but when we'll place the methods which we want to manipulate the Model data?

I'm not sure what you are asking here, I could guess but it would be better for you to clarify.

 

[ArtOfWarfare]

It took me years to understand these things. I came to understand them by totally ignoring them and realizing how impossible it was to maintain my code.

MVC looks like this:

Your M (model) is a collection of properties. You can implement setters and getters, but honestly, most of the time I can just write a header file and not even touch the implementation file. Alternatively, you can use Core Data to do the same sorts of things, but, at least in my experience, Core Data tends to be overkill. If you're dealing with writing huge databases that need to be saved and opened and searched and scanned and relationships to be maintained and on and on, then Core Data is probably right for your app. Otherwise, it's probably overkill and you'll waste time trying to figure out how it works when you could instead actually be making your app a different way.

Your V (view) is often just a collection of .xib files. If you want to make a brand new UI component, then you might have to actually code it yourself, but outside of games, the components you can drag and drop from AppKit (or UIKit) into your .xib file are generally adequate.

Your C (controller) is where your logic goes. They manage interactions between your models and views.

Protocols/delegation are what keep your model and views reusable. You write protocols for your data objects and for your view objects (assuming you had to make some) so that they can recognize actions that they need to inform your controller about. You then have your controller assign itself as a delegate for your data objects and view objects and have it implement the delegate methods.

 

[chown33]

See this:
Cocoa Core Competencies

It has brief individual articles on Delegation, MVC, and many other fundamentals. Each article then has links to reference documentation on each subject.


For examples, look at Apple's sample code.

The reference docs often have links to specific samples. For example, the reference doc for NSArray links to 5 sample code projects. Find the links by finding the word "sample" on the page.

 

[Senor Cuete]

We?

What mean "we", whiteman - Tonto

 

[PatrickCocoa]

Stop / Start

Stop reading. Start coding.

 

[ArtOfWarfare]

Stop reading. Start coding.

Good suggestion.

I think if I write a book going from nothing to everything on programming, I'm going to have the person write a program with a terrible structure near the beginning, then in the end suggest they add some feature that should be trivial were it well coded (but it's not so the task is basically impossible), then cover MVC, scrap the entire terribly structured code and have them do it over with proper MVC.

 

[larswik]

Are you starting to learn programming with Objective C? If so I would think about starting simpler with C and understanding that before you move on. I start with objective C and got lost real fast. I stepped back to C and when I understood that I moved to Object C and it was much easier to understand.

 

[firewood]

There is no console. Your app doesn't call the OS and tell it what to do. Cocoa is event driven. Thus the OS calls your app when the OS is good and ready. Delegates are what the OS (and customized objects) call when they want to do something. You don't get to code what your app does in the app delegate. You get to figure out what OS events you want to respond to, and make delegate method functions so that your app responds.

Learn this. Or give up and go back to doing ancient-style Linux command line tools.