The Carbon framework will soon be deprecated in the near future.
My first question is whether the deprecation is targeted towards a particular release i.e. whether it's incompatible with 64-bit machines?
Also, since it is known to be deprecated, we are working towards removing the Carbon dependencies and using Cocoa framework instead. While removing some, I came across the use of EventRecord struct defined in the Events.h file. What should be the Cocoa equivalent of the above struct i.e. I should be able to loop through the Event records while using cocoa too.
Carbon does work with 64-bit machines, but it doesn’t work in a 64-bit mode, it works in 32-bit mode. You definitely want off it.
Cocoa has NSEvents (NSEvent.h), but a lot of what EventRecord appears to cover just isn’t relevant in Cocoa. Like, you don’t have to worry about “this portion of the window was uncovered” events—the system just calls “-drawRect:” on your NSView subclass.
Related
This question pops up quite often here, even if just implicitly when users mistag their iOS questions. So, what’s the difference between Xcode, Objective-C and Cocoa?
Objective-C is a programming language. It could be said that it’s just a description of what valid Objective-C programs look like and what they mean. If you have a source code listing written in Objective-C, you need an interpreter or a compiler to put the listing to work. Languages like Objective-C are usually compiled, so most people use a compiler (like LLVM). Objective-C is almost exclusively used to develop for iOS and OS X, but there are other uses, too – as an example, some people write Objective-C for Linux.
You can use a text editor to write the sources and a compiler to turn them into an actual programs, but with modern technologies there’s much more to take care of, so that there is another program to make your job easier. These are called Integrated Development Environments, or IDEs. An IDE offers you a convenient way to edit the sources, compile them, debug the resulting programs, read the documentation, and many other things. Xcode is one such IDE. An important observation here is that Xcode does not compile your sources itself, it just calls the standalone compiler (LLVM). And Xcode is not the only IDE you can use to develop Objective-C apps – there’s AppCode, for example.
Writing iOS or OS X apps from scratch each time would be very time-consuming. That’s why Apple provides the developers with a good set of libraries. The libraries are simply a huge amount of source code written by Apple, and this source code takes care of most things that apps have in common. These libraries are called Cocoa.
Now, if you can’t figure out how to extend a class, you are most probably talking about Objective-C. It doesn’t have anything to do with Xcode or Cocoa, you could be very well writing some GNUstep code for Linux using Vim as an IDE and GCC as a compiler. On the other hand, if your Xcode build process fails because of some mysterious setting, or if you’re trying to build a static library in Xcode, that’s clearly an Xcode issue. And if you can’t figure out how to use some NSObject facility or the NSFileManager class, that’s Cocoa. (But it doesn’t have to be Xcode-related, as you could use AppCode or TextMate as your IDE!)
Originally available on my blog. Feel free to link to the blog post or this question when retagging or explaining the difference.
Xcode is the integrated development environment (IDE)—the application—that developers use to write software for iOS and/or OS X. It includes the editor, the build system (determining what to build to produce the desired target), and quite a few other things.
Objective-C is the main language that developers write such software in. They may write bits of it in pure C, use C++ or combine it with Objective-C (producing Objective-C++), or write some or all of the program in another language entirely, such as MacRuby, Java (with j2objc), or C# (with MonoTouch).
Xcode includes the Clang compiler, which turns code written in Objective-C, C, and a few other languages into executable code. Most error messages come from Clang, and Xcode relies heavily on it for search indexing, syntax highlighting, and name completion of Objective-C code.
Cocoa and Cocoa Touch are application frameworks. Each one is a suite of many individual frameworks (libraries stored in folders named blahblah.framework), such as:
Foundation (both): General object-oriented utilities, including NSString, NSURL, NSFileManager, etc.
Core Foundation (both): Mostly the same thing, but different, mainly in having a C-based API rather than Objective-C
Application Kit (Mac): Application and windowing framework
UIKit (iOS): Application and windowing framework
Core Graphics (both): Drawing
Core Animation (both): Sprite-management and animation framework
(and many, many more where they came from, especially on the Mac)
So:
You can use a framework besides Cocoa or Cocoa Touch, but you'll have to have some Cocoa/Cocoa Touch code, at some level, in order for your application to talk to the system, receive events, draw, etc. Frameworks that specifically target Mac and/or iOS will include the relevant wrappers for you, at varying levels of quality.
You can use a language besides Objective-C, but you'll have lots of syntactic awkwardness, as most of Cocoa and Cocoa Touch are designed for Objective-C's unique syntactic features (particularly selectors).
You can use an editor besides Xcode, and you can even use a build system besides Xcode (such as make), but Apple's App Stores expect apps built a particular way (especially with regard to code signing), so unless you're not targeting the App Stores, any other build system has to replicate what Xcode does or risk its users getting rejections.
A clear mistake is failing to differentiate Xcode from everything else. Xcode is the tool you are using to program in - to edit code, run code, etc. So if you are having trouble with the tool (e.g., the window doesn't show you your code properly, or you're having trouble drawing your interface, etc.), that's an Xcode problem.
If you don't understand why your code doesn't work, you're probably having an Objective-C problem or a Cocoa problem. But you won't necessarily know which.
It's an Objective-C problem if the root of your trouble is that you don't know how the language works (e.g. you don't know what the asterisk is for, or that declaration is not instantiation, or that messages to nil do not error out but don't do anything either).
It's a Cocoa problem if you don't grasp the delegate architecture or how a view controller works.
But my experience of the way people pose questions is that you may be ignorant of which of these you are ignorant of. I don't mean you personally, I mean all of us. This can make it difficult to pose the question properly because you don't know what exactly it is that you don't know — if you did, you'd know it and you probably wouldn't be having a problem (you'd be fixing the problem and on to the next thing).
So I'm trying to use AFNetworking library for REST services on a project I want to build on my 2006 Macbook. The Macbook is a first-gen 2006 32-bit Core Duo w/ snow leopard.
I'm fairly new to Objective-C development and I'm following the tutorial to get started with AFNetworking here: https://github.com/AFNetworking/AFNetworking/wiki/Getting-Started-with-AFNetworking
Using xcode 4.2 my problem is that right away when I create a new project and try and build I get: Semantic Issue - Synthesized property 'window' must either be named the same as a compatible ivar or must explicitly name ivar.
I checked the Build Settings of my new project and for some reason xcode by default assumes 64-bit Intel architecture when my machine is 32bit?! weird. I swapped it to 32-bit and this is where the error came up.
So I can correct this Semantic Issue now by explicitly creating my own window instance var in AppDelegate via:
NSWindow * _window;
I read about this on building out for 32bit objc:
Synthesizing a property without instance variables which seems VERY common (lack of ivar declarations) in lots of public github project code I see. Is everyone forcing 64-bit on us now or just too lazy to create the instance vars? :(
So my problem is that it looks like AFNetworking library was built out for 64-bit Intel because when I add AFNetworking to my project I get the same Semantic Issue ivar errors all over the place. Looking at the library code there are no explicit instance variables declared throughout the code for any properties.
Am I completely screwed here? I could fix this situation by manually creating instance vars for all the properties but this would be such a pain for long-term project maintenance.
I guess what I'm wishing here is that there was some sort of compiler flag that I could add that would fix this all in one-shot?? but I'm guessing that I'm out of luck and it's simply time to trash this Macbook and pickup a new modern one.
Automatically synthesized instance variables require the "modern" Objective-C runtime which is only available on 64-bit machines. So, unfortunately you are correct that you can't just set a compiler flag to fix this. The solution is indeed to add instance variable declarations for the properties in the class(es) you're trying to use.
I'm not sure that's so difficult that it's worth throwing out your computer... That said, the conveniences offered by the modern runtime are pretty tempting to developers, and you're not likely to see a lot of new code going forward that maintains support for 32-bit Macs. Apple only sold 32-bit Intel Macs for a short time, and Lion requires a 64-bit Mac, so the proportion of people using 32-bit Macs is already quite small, and rapidly getting smaller.
I am trying to compile a library originally written for Cocoa. Things are good until it looks for the function marg_setValue(). It says there is a syntax error before char in
marg_setValue(argumentList,argumentOffset,char,(char)lua_toboolean(state,luaArgument));
(it's talking about the third argument, not (char) )
I am trying to port LuaObjectiveCBridge to the iPhone. It has two choices, either using Runtime or Foundation. I have discovered there are some problems with foundation so I am trying runtime. But the compiler is not co-operating.
Check to see if you can get rid of the marg_XXX macros:
they are deprecated and not considered as reliable.
marg_list is to be used with objc_msgSendv which is absent from modern runtime.
I suggest to go with NSInvocation. It is pretty simple to use, and powerful enough for a bridge. Check this entry for completeness.
The modern Objective-C ABI/API is available on Cocoa Touch. It lacks some of the legacy features of the 32-bit desktop runtime (namely, ones that were horrendously fragile).
marg_setValue() and friends are a part of that legacy runtime that is not supported in Objective-C 2.0. It was -- always was -- broken anyway. You aren't missing much.
The real question is: What are you trying to do?
The Objective-C Runtime Reference says:
“Deprecated” below means “deprecated in Mac OS X version 10.5 for 32-bit code, and disallowed for 64-bit code.”
and I would like to use class_setSuperclass in Max OS X version 10.5 even though I still can do it the compiler gives warning telling me its deprecated but it still builds and the Bundle is still usable.
My question is what would be the equivalent in Max OS X 10.5?
On a guess using it is probably not a good idea. I know with the shift towards 64 bit several things in the runtime changed and didn't have a replacement.
The docs even explicitly say not to touch, and doesn't give exception to that.
You can however use class_addMethod to add functionality to a given preexisting class. However, that is also doable via categories.
You can use class_replaceMethod to override a method as well, another possible method is to use a category (or class_addMethod) to add a replacement method. Then using method_exchangeImplementations you can swap them so as to have the original still available for calling.
In general though most of this is kinda dark voodoo, and unless you're comfortable with and willing to test a lot, I'd look for an alternative design.
There may not be a direct equivalent.
I know every time I've played with the class hierarchy at runtime I've been burned. You should be able to achieve the same results, albeit more verbosely via delegation, and I'd imagine that's what they want.
It seems that Cocoa seems to be the main platform for Objective-C. GCC (which Xcode uses) supports Objective-C so it must be available on a wide range of platforms.
Are there any notable cross-platform projects that use Objective-C but not Cocoa (or its open source cousin GNUStep)? Is it really used outside the Apple ecosystem?
Objective-C has also been popular in the scientific and financial services communities. There are still many Objective-C based applications deployed in banking, mostly on the trading analysis front. A friend works on a nearly million line of code Objective-C based analysis and trading engine for which they have written their own class hierarchy from scratch.
At one point, one of the more popular Linux window managers was written in Objective-C. That was a few years ago and may no longer be the case.
The LLVM compiler also compiles Objective-C, including having full support for Blocks. It is quite portable, too.
There is also David Stes's Portable Object Compiler. It compiles Objective-C to C and uses a class hierarchy that is based quite directly upon the original ICPak class hierarchy from StepStone.
It seems what you're asking is if Objective-C is ever used without Cocoa, or GNUstep, or Cocotron, or any API like them.
The answer is basically no. Without an API like Cocoa (or GNUstep, etc.), Objective-C isn't very useful. For example, without NSObject, retain and release wouldn't even exist. A ton of very important features are built into these APIs, so it's somewhat pointless to use Obj-C without one of them.
Yep, there sure are. The one I can think of from the top of my head is Cocotron. An effort to port AppKit to Windows.
http://www.cocotron.org/
Aside from that, Objective-C can be used on any platform that gcc will run on. You won't have the wealth of frameworks that are available in Cocoa on OS X or the iPhone, although as you mentioned, GNUStep does a pretty good effort.