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.
Related
It appears the language is the same for either device ios or mac os on a mbp, but if I learn Objective-C in a tutorial, won't I also need to learn cocoa or cocoa touch to program effectively?
I'm not sure how to start on my path of learning to program an ios device. I know I need to learn objective-c and that appears to work on all apple products. Then do I move to cocoa touch for ipad and iphone? What comes after objective-c?
The type of project is akin to a web app but native objective-c app instead. Have ui, buttons, the app hits some back end location, returns data, I put it on that same ui. Only, as stated, use objective-c and whatever framework and library to do it (that's my dilemma. I dont know what to do next after objective-c).
thanks.
Cocoa and Objective-c go hand in hand. For getting started, I would suggest going over some old WWDC footage and following some of the examples there.
As far as Cocoa and Cocoa touch are concerned, they are very similar in many aspects, same name conventions, similar structure, etc. Learn one, and you can easily pick up the other.
#craig adds:
I would further this answer by also mentioning that Objective-C is a programming language, while Cocoa/Cocoa Touch are collections of frameworks that are provided by Apple, and used by developers to add functionality to their programs. (Which are written in Objective-C.) The Cocoa frameworks contain various UI components like buttons, table views, sliders, etc. in addition to various fundamental classes like NSString and other text- and graphics-based APIs
I started my learning by watching thenewboston's xcode tutorials:
you can begin with this one
Good luck :)
I prefer books for some strange reason and I found that the Apress series of IOS development is really good. The book goes through developing iPhone and iPad apps using all kinds of Cocoa libraries. There's a lot of good books out there on the subject; I would go find one that looks like it would suit your needs.
The rejection of a recent edit I suggested gave me doubts about something I thought I knew on Objective-C.
I've lived under the assumption that the UIViews are part of iOS, that iOS is a descendant of Objective-C and that Objective-C has no default kits with any views.
I've tried some Google and Stack Overflow searches, but the results didn't seem trustworthy and were mostly about UIViews. Wikipedia seems to mention nothing about this .
Does Objective-C have views? Or is that, as I assumed before, a common misunderstanding?
The problem that I see is that iOS is NOT a descendant of Objective C.
iOS is the operating system (like Windows Linux OSX) whilst Objective-C is a programming language albeit one that most iOS and OSX apps are written in. However there are iOS apps written in Python and other languages,
iOS as such does not have views - these are part of the Cocoa-touch framework which is a set of libraries that run on iOS and can be called with Objective C code. Although in practice for the programmer the difference between calling code in iOS and Cocoa touch is not really clear if you are only writing for iOS devices, the split is clearer in OSX where you can write code just using OSX calls or can use Cocoa frameworks.
As noted the views are part of the Cocoa touch framework. This can be called by any language including Objective - C. Most languages do not include the ability to write GUIS as part of itself they usually make use of separate libraries to do this. For example Objective C has no GUI libraries itself but has had Cocoa touch written for iOS, Cocoa and Carbon (although that mainly uses a C binding) for OSX and GNUStep for Windows and Unix like OSes (and historically NeXTStep, OpenStep, Rhapsody, basically earlier versions of Cocoa, on various OSs and Stepstone's ICPak 201)
Objective-C is the open source programming language. UIKit(iOS) and AppKit(Mac OS) are what provide the visual elements - and this is not open source.
Objective-C itself doesn't have a UI, that's provided by other frameworks.
From what I have understood obj-c's views are part of the UIKit framework : check here
which is designed for constructing GUI applications on the iOS.
I don't think you can use this framework in other obj-c applications but on iOS. Probably there are other frameworks that have views which can be used.
Edit: And yes, good point by #Mark that you are confusing the Operating System with the Programming Language
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
First of all, is this possible?
If so:
What challenges would I encounter in making an XCode imitation for iPhone/iPod development for Windows or Linux?
I was thinking about using gcc as the actual compiler for the objective-c and (VB).NET for the IDE. Will that work?
It doesn't need to compile to iPhone OS until it is to be tested on the device or submitted to the app store. Perhaps it will be easier to compile to the local OS format (Windows or Linux) until "prime-time".
Is this concept possible? Comments? Ideas of how to implement?
If you wanted to support all of UIKit and Cocoa Touch, the problems would be insurmountable. You'd spend 2 years trying to get off the ground and then give up, while everyone else had fun developing apps for the iPhone and iPad and other devices. You would regret even trying it.
But if you wanted to create your own framework for making iPhone apps, built immediately on top of OpenGL, it might be possible. You would create a simulator that renders to an OpenGL view, and the final app would also render everything in an OpenGL view, touching none of UIKit. You would use pure C, or some robust cross-platform language like Lua, compiled or even interpreted. Incidentally, that's more or less how the Corona framework does it: built on top of OpenGL, touches little of the iPhone SDK, uses compiled Lua. They developed their own simulator, which only runs on OSX, but could probably relatively easily be ported to Linux.
You could even use Objective-C as the language, and make available a carefully chosen subset of the Cocoa API's by using (the iPhone compatible parts of) GNUstep Base. Then users could use standard classes like NSString.
Still, all of this is mostly interesting as a thought experiment, unless you got a team together to work on this as an Open Source project. It's harder than you think. Your simulator wouldn't be able to emulate the way that memory warnings are generated on the iPhone, for example.
If someone wants to develop iPhone apps on Linux, it makes more sense to just write the whole app in C/C++ using OpenGL, and then basically just smack that code onto a vanilla iPhone OpenGL project. That's the fastest path. The next possibility would be to use another language, which is also not too hard. But an "iPhone IDE" on top of that would be little more than putting an iPhone-like frame around the OpenGL view in Linux.
Actually, Felixyz touched on something your should take a look at. See: http://www.gnustep.org/ . They have binaries for just about every variant of *nix, OS X, and windows. The site claims "GNUstep seeks to be source code compatible with Cocoa and OpenStep, it can thus be used to develop and build cross-platform applications between Macintosh (Cocoa), Unix and Windows." It would be a good jumping off point for such a project,
I doubt all OSX's functionality is covered by GNUStep, but it's a start.
I'd imagine to develop iPhone/iPod apps on an alternate platform, you'd need to get Apple's includes (Legality is likely to be an issue), and apply all their toolchain patches, plus a million other things I'm probably overlooking.
What would be a better project is implementing the missing functions in GNUStep to support OSX apps seamlessly under the host platform. Maybe then you could run xcode native on your desired OS.
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.