What is the difference between carbon and cocoa ? For what type of applications we should use carbon and for what type of applications we should use cocoa ? Which is the best of both for developing applications in Mac OS ?
Short answer: For a new application, use Cocoa. Some legacy code may still use Carbon and if you don't need any new capabilities, it will continue to work.
Cocoa has an Objective-C API, and can be accessed from C and C++ code easily. Carbon is a pure-C API. There are both Cocoa and Carbon bindings for many other popular languages, but there are often some limitations.
Carbon is evolved from the original API for the original Apple Macintosh (and Apple Lisa) in the early 1980s. Specifically, when Mac OS X was released, Apple was unable to support some of the legacy Mac OS API functions, but provided a subset of legacy APIs called "Carbon", to ease the transition for developers who had pre-Mac OS X applications. They added thousands of new APIs and continued to fully support Carbon for several years, before finally deprecating it more recently. They have always said that Carbon is a dead-end and all developers should move to Cocoa.
Cocoa has evolved from the NextStep framework that Apple acquired and used as the basis to create Mac OS X. It's the "native" API for Mac OS X and the only way to access some of the newest capabilities.
Carbon was created to ease the movement to and from Mac OS 8 and 9. If your code needs to run under OS 8 or 9, then Carbon is the way to go. (Source)
However, if your software is designed for OS X, then you should emphasize Cocoa over Carbon.
Carbon is deprecated (it does not and will not exist in 64-bit).
For new application development, use Cocoa (I'm talking about native OS X application development the Apple-sactioned way. Obviously other alternative choices exist, such as Java, Python, Ruby, etc, which may be effective depending on your project type if a native UI is not required)
It depends on the scope and the functions of the application you're going to develop.
I'm going to be building an application that makes use of MacInTalk capabilities and the new OSX 10.7 international set of voices. The official documentation states that fine-tuning is provided only under Carbon APIs, while Cocoa APIs are more limited.
Specifically, these Speech channel settings are alterable via API in Carbon: rate, pitch, pitch modulation and volume attributes. This possibility seems to be unavailable via Cocoa.
On a side note, the most updated documentation of the Speech Synthesis Programming Guide dates back to 2006 and it might be the case that Cocoa access to the same functionality is out there, but it's not yet documented.
Related
Is it true :
Cocoa is an application environment that consist of several Frameworks
and each framework consist of several API
Application Environment -> Framework -> API
Is Carbon the other application environment in OSX?
All things that allow an application to talk to a computer are an "API." That's a very broad term. It may refer to something as small as malloc, or as large as Cocoa. All of these are "APIs" in the broadest sense of the term.
On Mac and iOS, "framework" can have a specific meaning, which is a dynamically loadable bundle in a specific format. It can also have a broad meaning of "a collection of libraries that work together." There is a Cocoa.framework, but there is also the broader architecture of "Cocoa" which is a way of attacking problems together with a set of tools for attacking problems in that way.
An "Application Environment" is any environment that applications can run in. So Mac OS X could be considered an App Environment, or you might consider Darwin to be an App Environment, or Cocoa, or Carbon. It depends on what you're comparing it to.
The point in all of this are that these are not industry-wide well-defined terms. They're used to mean a lot of overlapping things, and they are sometimes used slightly different ways even within the Apple docs.
If you're looking for a good reference on general terms and how Apple uses them, you want to read Cocoa Core Competencies.
What the wiki says :
Carbon is one of Apple Inc.'s procedural application programming
interfaces (APIs) for the Macintosh operating system. It provides C
programming language access to Macintosh system services. Carbon
provides a good degree of backward compatibility for programs to run
on the now-obsolete Mac OS 8 and 9, however these systems are no
longer actively supported since Apple released the final OS 9 update
in December 2001.
In a few words, BOTH Cocoa and Carbon are considered APIs.
Sidenote : Why do you care so much about terminology? I definitely wouldn't. IMHO, it's the inner logic and concepts that matter; and not, necessarily, how we call it. Just my 2 cents....
I have some basic familiarity with Objective-C, but prefer Ruby, so I'm thinking of playing around with MacRuby. Is it possible to use MacRuby to develop applications for the Mac App Store, or do I have to use Objective-C? (Note that I don't care so much about iOS/the iPhone and iPad store right now, just the Mac OS X app store.)
And to answer the actual question, yes, see http://lists.macosforge.org/pipermail/macruby-devel/2010-November/006475.html.
Short answer: Yes, you can, technically, build such an app. You need to revisit the store guidelines to know what requirements must be met to submit to the various stores.
This comes up sporadically; beyond the guidelines that #NSResponder mentioned, the reality is that you'll just be spending a lot of extra & unnecessary time if you decide to use MacRuby unless you plan on using some large chunk of already written Ruby code in your app.
Learning Objective-C is about 2% of the overall learning needed to be an effective Cocoa developer. The other 98% is everything from memory management model to standard idioms like KVC/KVO/delegation to NIB files to the myriad of classes & APIs throughout the system.
All of those things are written in Objective-C (or C) with documentation targeting Objective-C and examples written in Objective-C.
As well, the entire tool chain is focused on validating, compiling, indexing, debugging, and manipulating Objective-C.
If you want to use MacRuby to build a real Cocoa app, you are going to have to know Objective-C through and through anyway. And you are going to have to deal with whatever bugs and impedance mismatch is in the bridge layer, too.
Yes. As the Mac developer forums says:
My Mac app is not written in
Objective-C. Is this allowed on the
MacApp Store?
Yes, provided it also adheres to the
Mac App Store Review Guidelines at
http://developer.apple.com/appstore/mac/resources/approval/guidelines.htmland
the Mac Developer Program License
Agreement at
http://developer.apple.com/programs/terms/mac/mac_program_agreement_20101020.pdf
(via alloy)
Read the submission guidelines here: https://developer.apple.com/appstore/mac/resources/approval/guidelines.html
Hi just wondering how do you start writing programs for MAC OS X?
what language does it use? can I use objective C? which IDE do I use? any licensing fee should I know about.
Thanks.
Mac OS X is a great programming platform, as such you can use just about any language you like.
If you wish to write native applications using the Cocoa framework you'll probably want to be using Objective-C. You can download XCode as an IDE for free.
No licensing fees.
Xcode is the apple supplied IDE, and without external libraries some objective C is always required to build applications.
That being said xcode supports multiple types of langauges, and has extensions for many more - and C++ can be spliced in with objective C code - so if you prefer to code in C++ you can write a quick objective C wrapper and do all your own stuff in C++ - or indeed the langauge of your choice. There are a few other open source IDE's but I don't really recommend them - most of them crash on opening in new versions of Mac OS X.
Xcode is found in the developer package on your second mac install disk, or the latest version (with iphone SDK's) can be downloaded once registering on the Apple Developer Website, which you can become a basic member of for free.
As far as licensing goes, unless you plan to make a game for iOS there are no liscensing fees, unless you want a full subscription to apples developer website, which gives you a few extra things from them.
If your trying to write a game, consider using the SDL library, a cross platform wrapper for whole lot of operating system interface functions, including graphics - or you can use it as I do in combination with OpenGL for full 3D Support, hardware acceleration, ect.
Objective-C + Cocoa
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/Introduction.html
Apple suggests XCode
The native libraryfor OS X developed by Apple are called Cocoa. It provides OS X's graphical user interface, and other libraries such as Core Data for database acess, Core Animation for fast easy animation and video features in your software. These libraries are written in a mixture of C and Objective C (which is an extension of the C language). For best performance and best integration with the Mac operating system you should probaby look at developing in C, Objective C and perhaps some C++ as well.
There are some add-on layers that provide acces to the Cocoa libraries from other languages such as Ruby or Python. These are generaly of good quality and work well, so you can use these languages if your aplication does not need the very best performance. They are generaly considered to be easier to learn than the C family of languages and you can become productive very quickly.
Beyond that, you can use languages and toolkits that are platform-independent so your software will can run on Linux or Windows as well as the Mac. For example Python comes with a simple built-in GUI toolkit called Tkinter. You can use more powerful cross-platform toolkits such as Qt or WxWidgets with C or C++ but have excellent bindings for Ruby, Python and other langauges. This is an approach I am using of a project, with Python and Qt.
Others have mentioned Apple's integrated development environemnt (IDE) called XCode. I have only toyed with it, but it looks very powerful for true native development of Cocoa applications.
I want to ask an very basic question about the iPhone application. what does mean of the the 'Cocoa' in iPhone application? Is there are relateionship between the memory management and the Cocoa? thank you very much.
Cocoa is just the code name for one of the Apple API's, originally provided on the Mac (I used to code for that on my old iMac). One of the others was Carbon.
Wikipedia has a more in-depth description that will do it far more justice than my brief snippet above.
Cocoa is the primary Mac OS X API. For iPhone development, a variant of this API called Cocoa Touch is used.
Apps developed for Cocoa can take advantage of a garbage collector, but this is not available in Cocoa Touch applications, where the application must ensure it manages allocation and destruction correctly.
Cocoa is the Apple API, the set of technical tools (not talking about IDE here) delivered by Apple in order to develop MacOS X applications. Cocoa Touch is the iPhone application API.
When you mention Memory Management in Objective-C on Mac/iPhone, you usually mean methods and of NSObject (retain, release, autorelease, retainCount). This feature is provided by the Foundation library, which is a part of Cocoa and Cocoa Touch.
However, Objective-C is now tightly connected to Mac and iPhone development, it is not unusual to assimilate Foundation to the language.
I'm trying to build a dual platform application for a company of my own I'm trying to start at night.
I have the .NET version done, but have not finished the UI part. I'm thinking of buying some 3rd party controls.
If I buy these controls, however, they clearly will only work in my Windows version. I'm wondering if I should try to do the UI in GTK# and use Mono with CocoaSharp or just build the thing in MS technology and teach myself the Mac side?
I'm just really unfamiliar with the Mac world and am wondering how much of a learning curve there might be.
I've thought perhaps of rewriting my core logic in Ruby or Python. This why I could use the .NET version with .NET controls and presumably hook the same code up on the Mac.
It's an educational app targeted at consumers. As such, it shouldn't require a lot of technical sophistication to install.
If the non-visual part of the .NET application is quite big compared to the UI, then you can go full .NET and adopt the following two-steps strategy:
Non-Visual Part
Develop the non-visual .NET part to be the most platform independent.
Platform dependent code for non-visual code should be isolated in small classes that provide the same interface so they could be plugged according to the platform.
User Interface
Use System.Windows.Forms (or your favorite toolkit) for Windows
Use a Cocoa bridge (see this page for the choices) for Mac OS X.
You still can benefit from learning Objective-C: as the Cocoa bridges are usually heavily based on the Apple's API, you will find a lot of help in the Apple's sample code (which are in Objective-C).
On Windows, the application will run with the Microsoft .NET runtime and on Mac OS X, the application will run with the Mono runtime.
The DeepMeta application uses this strategy. As you can see the user experience is quite good on both platforms.
Avoid using cross platform UI tools; the result will never be as good as a native implementation, which is especially bad on the OS X where most customers expect a certain level of polish in their applications. Implementing the core logic in a platform independent language like C++ and maintaining a different code base for the interface on each platform can be a good solution, especially if you have a very complex model.
Anyway, you shouldn't have too much difficulty learning Cocoa if you're a good .NET programmer; I did the reverse several years ago and didn't have much trouble. Objective-C is more C oriented than C#, but if you know the basics about pointers and such you're going to be okay. Cocoa and .NET definitely have their differences in certain areas, but they're both high level frameworks which you shouldn't have too much trouble understanding. Get a good book (Hillegass is the go-to author) and go through it so you understand how the two APIs use different design patterns in certain areas, and don't try to fight the framework if it's different than what you're used to.
In my experience this will make you a better programmer in the long run by expanding your knowledge, even if you don't write any more Cocoa applications.