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....
Related
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
I am trying to test Objective-C on Linux (Ubuntu 10.04), mainly to decide if it's worth it to get a Mac and XCode. I have to like a language before I seriously consider programming in it (even more so when I have to pay a lot for it)
I am using gcc (with gobjc++). But this of course does not include the Foundation Kit and the rest of the Cocoa API (not overly concerned about this one).
Short of GNUStep, what is the best way for me to get into Obj-C programming in Linux or Windows? I want to get at least class in the FoundationKit.
You have two options:
GNUstep, which is focused on Linux
Cocotron, which is focused on Windows
Those are the only freely available implementations of Foundation that I'm aware of.
Honestly, the language is hardly ever used outside of the Apple ecosystem, so you're not going to get a first-class experience here. Not knocking those groups' efforts, but if you're looking for something comparable to what you get on OS X, it just isn't there.
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.
Is there any other scripting language that can be used to embed scripts inside applications, which can access Mac OS X, or application classes with the same features, or most of the features seen in F-script?
The scripting language with the best support on the Mac is still AppleScript. But unlike F-Script, it cannot directly access the Objective-C level, it can only use what the target application chooses to expose for scripting.
There are Objective-C bridges for Perl, Python, and Ruby. I suppose those can embedded to provide scripting to your application.
Nu is an interesting option, although it isn't very popular yet.
A lot of people seem to like JSTalk.
But probably Applescript is your best bet: integrated into the system and all that.
I would say F-Script for many reasons. It has many unique features and is extremely tightly integrated with Cocoa and the Objective-C runtime. You can for example inspect various Finder classes (windows, icons, coverflow view...) and it's very easy (one or two lines of code) to start or control other processes. I don't think there is any good reason to prefer AppleScript. It's good for very short scripts, but will probably drive you crazy if you want to do something more complex.
Also, MacRuby is going to rock when it's a bit more stable, and some serious stuff has been accomplished using PyObjC as well, although I don't think it's very actively maintained anymore.
If you don't need F-Script graphical introspection tools, which are quite unique, there are some decent scripting languages that you can embed in applications. See in Particular RubyCocoa (for Ruby), PyObjC (for Python), JSTalk (for JavaScript) and CamelBones (for Perl). They are based on bridges between Cocoa and a foreign object model, which leads to some complexities. This is different from F-Script, which is directly built for the Cocoa object model. When ready, MacRuby might be an option too, but the syntax for manipulating Objective-C objects is not very nice (it improves on RubyCocoa, though). Nu is also an option: directly built for Cocoa like F-Script, but with a strong Lisp flavor.
MacRuby is an implementation of Ruby 1.9 that uses the Objective-C runtime and garbage collector. It can be embedded in a Objective-C application.
Even if the last available version is only 0.6, it is reported to be stable enough to be used in applications.
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.