macOS Carbon vs. Cocoa

[zyzzogeton]

Is it worth learning Objective-c to use Cocoa? Cause Objective-c looks hard and not clean

 

[gnasher729]

Is it worth learning Objective-c to use Cocoa? Cause Objective-c looks hard and not clean

If you want to write iPhone software, or Mac software that you can maintain in a few years, learning Objective-C is an absolute must. Assuming that you know C (and if you don't, you can go home anyway) , and assuming that you are willing to learn about object oriented programming (and if you don't, see above), Objective-C is a much smaller language than say C++, a lot easier to learn to use well, makes it a lot easier to write _readable_ code, and is very, very powerful.

 

[Catfish_Man]

Objective-C/Cocoa is much easier than Carbon.

 

[foidulus]

Essentially Carbon doesn't have a very bright future

While Apple hasn't explicitly come out and said it, they seem like they are trying to distance themselves as much as possible from Carbon and moving people towards objective-c. For example, they scratched 64 bit Carbon which basically means that if you want a native 64 bit GUI, you pretty much have to go Cocoa(You could go Java too, but then it wouldn't be native).

 

[firewood]

Is it worth learning Objective-c to use Cocoa? Cause Objective-c looks hard and not clean

Objective-C and Cocoa are much cleaner and more scalable than Carbon. Having written apps in both, I wouldn't call the Carbon API easy. While some things might be easier, others would be extremely difficult.

I would learn to use some plain C, as well as its superset, Objective-C.

imho.

 

[Chirone]

a lot easier to learn to use well, makes it a lot easier to write _readable_ code, and is very, very powerful.

you haven't seen the legacy code i'm dealing with

also at one point made xcode crash every time it tried to open a project, and i deduced it was due to a method name being overly long... if xcode didn't complete writing your method calls out automatically then i would say objective c is one of the slowest languages to write because you just gotta keep typing and typing and typing and getting nowhere because of the ridiculously long method names (albeit easy to read/understand)

i thought carbon was dropped altogether and so cs4 wasn't going to be released on mac, but then i must have been told wrong?

i love how when mac upgrades to the next version all your code is suddenly broken, and none of your special hardware works anymore. keeps things up-to-date and money going into apple's pockets

 

[lee1210]

you haven't seen the legacy code i'm dealing with

also at one point made xcode crash every time it tried to open a project, and i deduced it was due to a method name being overly long... if xcode didn't complete writing your method calls out automatically then i would say objective c is one of the slowest languages to write because you just gotta keep typing and typing and typing and getting nowhere because of the ridiculously long method names (albeit easy to read/understand)

i thought carbon was dropped altogether and so cs4 wasn't going to be released on mac, but then i must have been told wrong?

i love how when mac upgrades to the next version all your code is suddenly broken, and none of your special hardware works anymore. keeps things up-to-date and money going into apple's pockets

If the legacy code doesn't need alteration, it might be easier to just build the legacy code as a static library with GCC, then just link to it with XCode and call the methods needed in the new code.

I guess i'd say if you're using XCode, you don't keep typing and typing, you type [<object or class>, then esc and use code completion. This is the most compelling feature of any IDE in my opinion.

Re: CS4, it will be on mac, it will not be 64-bit. This is because apple decided carbon wasn't getting 64-bit support. Adobe's code needs to be dual-platform, so they've stuck to a lot of C/C++ as far as I understand it. Any Objective-C they wrote couldn't be used on Windows, and I guess the custom code they have for the interface for each platform is already enough for them to maintain. I'm sure Apple considers this a thorn in their side, because they want everything on Cocoa, and I'm sure adobe considers Apple a thorn in their side because they must support OS X but the API they use is no longer being extended dramatically to allow them to use the new whiz-bang features.

Re: OS updates... yes, they tend to break things. But code still works fine on the existing version, and I view the alternative as eternally being backward compatible, which i think stunts innovation. it is unfortunate for developers, but I think it's worth it for users to get big improvements.

-Lee

 

[kainjow]

While Apple hasn't explicitly come out and said it, they seem like they are trying to distance themselves as much as possible from Carbon and moving people towards objective-c. For example, they scratched 64 bit Carbon which basically means that if you want a native 64 bit GUI, you pretty much have to go Cocoa(You could go Java too, but then it wouldn't be native).

Last WWDC when they announced that Carbon wouldn't be fully 64-bit, I think that was as good as any of an official statement on the issue. I was there at the session when they said it, but I don't remember the exact words. It was pretty clear though that Carbon shouldn't be used anymore for new development.

 

[Krevnik]

Re: CS4, it will be on mac, it will not be 64-bit. This is because apple decided carbon wasn't getting 64-bit support. Adobe's code needs to be dual-platform, so they've stuck to a lot of C/C++ as far as I understand it. Any Objective-C they wrote couldn't be used on Windows, and I guess the custom code they have for the interface for each platform is already enough for them to maintain. I'm sure Apple considers this a thorn in their side, because they want everything on Cocoa, and I'm sure adobe considers Apple a thorn in their side because they must support OS X but the API they use is no longer being extended dramatically to allow them to use the new whiz-bang features.

Two things:

1) CS4 is out on the Mac now. I own a license.
2) Adobe did say that 64-bit on the Mac wasn't coming until CS5 or so. You can still write portable apps using a Obj-C UI (see Handbrake as a good example of a C library providing core functionality, with Obj-C driving the UI which talks to it). However, because Adobe has so much code in C/C++, porting the UI over would take time they didn't have for CS4. They were depending on Carbon going 64-bit so they could avoid having to port the UI to a new language on the Mac side of things.

Personally, Obj-C is just different. It looks hard/unclean because it is not what people think when they get into programming these days. They are so used to everything being based on C-syntax that they just don't know anything else.

I've been pleased with Obj-C/Cocoa as a development environment. Sure, the language will take a bit of time to get used to, but the framework is extremely useful, and quite powerful. It replaces a lot of the grunt work you normally have to do in C/C++ when building object models, and really takes the cake as a rapid development framework. I can prototype some apps in a couple hours, rather than days thanks to things like CoreData, Interface Builder and Bindings.

 

[Chirone]

Two things:

1) CS4 is out on the Mac now. I own a license.

that's what we said about cs4
well... we said it wasn't 64bit but yeah, it's been out for a long time already

I've been pleased with Obj-C/Cocoa as a development environment. Sure, the language will take a bit of time to get used to, but the framework is extremely useful, and quite powerful. It replaces a lot of the grunt work you normally have to do in C/C++ when building object models, and really takes the cake as a rapid development framework. I can prototype some apps in a couple hours, rather than days thanks to things like CoreData, Interface Builder and Bindings.

i'm not a fan of interface builder. mainly because i can't see any code that it generates. the interface just magically works or doesn't (in most of my cases it doesn't )
core data and bindings are great concepts. a lot more streamlined than actually going in there and doing all those monotonous tasks yourself...
although i have managed to make core data's redo capabilities crash and i have absolutely no idea why.
imo there aren't enough examples for core data and it makes it a definate non-trivial task to begin a program from scratch

 

[Thomas Harte]

i'm not a fan of interface builder. mainly because i can't see any code that it generates. the interface just magically works or doesn't (in most of my cases it doesn't )

That's because Interface Builder doesn't generate any code. You're too used to things like ye olde MFC which tried to hack rapid-application development onto pre-existing frameworks.

If in Interface Builder you wire up a particular control to message a particular method, all that goes into the NIB is the name of the method. Objective-C is fully reflective, which means that the methods and instance variables of any class can be queried and looked up by name at runtime. So the message goes straight through with no code inbetween. There's no message map or secret handling code — there's no code at all. It's essentially a language feature.

To be honest, I think the thing that would help you most at this stage might be to read more about Objective-C, especially if it's your first fully reflective language.

 

[Chirone]

well... it makes it slightly harder to program interface elements without IB when you want your code to generate UI elements since you don't know how things were done in the first place and the only quick reliable source is non-existent

kinda like with core data... like how trying to add to the to-many relationships by programaticaly making an entity when a property of another has changed

 

[Thomas Harte]

well... it makes it slightly harder to program interface elements without IB when you want your code to generate UI elements since you don't know how things were done in the first place and the only quick reliable source is non-existent

Obviously this is true; you can't use Interface Builder to generate example code to learn about programmatic generation of interface elements. However, that's not because Interface Builder generates the code and doesn't show it to you, it's because interface elements know how to generate themselves directly from [N/X]IB files, so that code is no more inspectable that — for example — how an NSTextField responds to a mouse click. I assume this stuff is all part and parcel of the NSCoder approach to saving and loading classes (which is near identical to Java's serialisation as I understand it).

In general it's all relatively easy stuff though. All controls subclass NSView, so initWithFrame: should always be available for creating a new control at a specified position. Supposing you have an existing NSView and you want to add an NSTextField to it, you could do:

NSTextField *newTextField = [[NSTextField alloc] initWithFrame:<whatever>];
[view addSubview:newTextField];

Specific text field properties can be set using NSTextField-specific methods (probably before you addSubview), and you can always use setDelegate: to set yourself as a delegate for whatever methods you're interested in.

 

[Krevnik]

well... it makes it slightly harder to program interface elements without IB when you want your code to generate UI elements since you don't know how things were done in the first place and the only quick reliable source is non-existent

The number of times where I felt it was required to generate UI controls programatically? Once. All the methods you need are documented, but there may not be tutorials, per se.

The last time I wrote code to build UI on the Mac or Windows was for a custom control. Neither side is really at its best when you are programmatically building it anymore (minus a few NIB tricks so you can split up the UI into more manageable chunks, and load NIBs on-demand). There are just so many knobs and dials that it can get out of hand quick. Thankfully Apple provides sane defaults on their controls when you do need to alloc one up yourself.

kinda like with core data... like how trying to add to the to-many relationships by programaticaly making an entity when a property of another has changed

Sounds like you need to assign that entity to one of your classes that subclasses NSManagedObject, so you can intercept the setter and perform actions on it. This sort of stuff /is/ documented because that is exactly what it is there for, to let you extend the behavior.

 

[Chirone]

Sounds like you need to assign that entity to one of your classes that subclasses NSManagedObject, so you can intercept the setter and perform actions on it. This sort of stuff /is/ documented because that is exactly what it is there for, to let you extend the behavior.

i had done that, and it worked, except when i hit undo and redo it crashed. and if i hit undo, deleted the entity then made a new one it would also crash.

 

[Krevnik]

i had done that, and it worked, except when i hit undo and redo it crashed. and if i hit undo, deleted the entity then made a new one it would also crash.

Look at undo grouping (part of NSUndoManager), my guess with so little information at hand is that your edits were perceived as multiple edits, and stored separately on the undo stack. You would get your OM in a weird state if you had two linked changes, and were able to undo one at a time.

EDIT: I see the other thread now, and it sounds more like the entity may be getting created programmatically outside the context of a Managed Object Context. If that is happening, there is a lot to CoreData that flat out breaks, because all entities need to come from a managed object context.

 

[Chirone]

Look at undo grouping (part of NSUndoManager), my guess with so little information at hand is that your edits were perceived as multiple edits, and stored separately on the undo stack. You would get your OM in a weird state if you had two linked changes, and were able to undo one at a time.

yeah that's what i was thinking as i posted that last reply

sorry for hijacking this thread...