- Learn Objective-c On The Mac Pdf
- Learn Objective C Pdf
- Cocoa Dev Central Learn Objective C Free
- Learn Objective C Free
Starting with Objective-C 2.0, the Objective-C runtime implemented an optional garbage collector, which is now obsolete and deprecated in favor of Automatic Reference Counting (ARC). In this model, the runtime turned Cocoa reference counting operations such as 'retain' and 'release' into no-ops. Joe Burgeess has the process down cold - except for the glaring error almost everyone has been making for a few decades. First learn programming, then learn a. Learning Cocoa with Objective-C: Developing for the Mac and iOS App Stores Buttfield-Addison, Paris, Manning, Jonathon, Nugent, Tim on Amazon.com.FREE. shipping on qualifying offers.
Objective-C is the primary programming language you use when writing software for OS X and iOS. It’s a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime. Objective-C inherits the syntax, primitive types, and flow control statements of C and adds syntax for defining classes and methods. It also adds language-level support for object graph management and object literals while providing dynamic typing and binding, deferring many responsibilities until runtime.
At a Glance
This document introduces the Objective-C language and offers extensive examples of its use. You’ll learn how to create your own classes describing custom objects and see how to work with some of the framework classes provided by Cocoa and Cocoa Touch. Although the framework classes are separate from the language, their use is tightly wound into coding with Objective-C and many language-level features rely on behavior offered by these classes.
An App Is Built from a Network of Objects
When building apps for OS X or iOS, you’ll spend most of your time working with objects. Those objects are instances of Objective-C classes, some of which are provided for you by Cocoa or Cocoa Touch and some of which you’ll write yourself.
If you’re writing your own class, start by providing a description of the class that details the intended public interface to instances of the class. This interface includes the public properties to encapsulate relevant data, along with a list of methods. Method declarations indicate the messages that an object can receive, and include information about the parameters required whenever the method is called. You’ll also provide a class implementation, which includes the executable code for each method declared in the interface.
Relevant Chapters:Defining Classes, Working with Objects, Encapsulating Data
Categories Extend Existing Classes
Rather than creating an entirely new class to provide minor additional capabilities over an existing class, it’s possible to define a category to add custom behavior to an existing class. You can use a category to add methods to any class, including classes for which you don’t have the original implementation source code, such as framework classes like
NSString
.If you do have the original source code for a class, you can use a class extension to add new properties, or modify the attributes of existing properties. Class extensions are commonly used to hide private behavior for use either within a single source code file, or within the private implementation of a custom framework.
Protocols Define Messaging Contracts
The majority of work in an Objective-C app occurs as a result of objects sending messages to each other. Often, these messages are defined by the methods declared explicitly in a class interface. Sometimes, however, it is useful to be able to define a set of related methods that aren’t tied directly to a specific class.
Objective-C uses protocols to define a group of related methods, such as the methods an object might call on its delegate, which are either optional or required. Any class can indicate that it adopts a protocol, which means that it must also provide implementations for all of the required methods in the protocol.
Relevant Chapters:Working with Protocols
Values and Collections Are Often Represented as Objective-C Objects
It’s common in Objective-C to use Cocoa or Cocoa Touch classes to represent values. The
NSString
class is used for strings of characters, the NSNumber
class for different types of numbers such as integer or floating point, and the NSValue
class for other values such as C structures. You can also use any of the primitive types defined by the C language, such as int
, float
or char
.Collections are usually represented as instances of one of the collection classes, such as
NSArray
, NSSet
, or NSDictionary
, which are each used to collect other Objective-C objects.Blocks Simplify Common Tasks
Blocks are a language feature introduced to C, Objective-C and C++ to represent a unit of work; they encapsulate a block of code along with captured state, which makes them similar to closures in other programming languages. Blocks are often used to simplify common tasks such as collection enumeration, sorting and testing. They also make it easy to schedule tasks for concurrent or asynchronous execution using technologies like Grand Central Dispatch (GCD).
Relevant Chapters:Working with Blocks
Error Objects Are Used for Runtime Problems
Although Objective-C includes syntax for exception handling, Cocoa and Cocoa Touch use exceptions only for programming errors (such as out of bounds array access), which should be fixed before an app is shipped.
All other errors—including runtime problems such as running out of disk space or not being able to access a web service—are represented by instances of the
NSError
class. Your app should plan for errors and decide how best to handle them in order to present the best possible user experience when something goes wrong.Objective-C Code Follows Established Conventions
When writing Objective-C code, you should keep in mind a number of established coding conventions. Method names, for example, start with a lowercase letter and use camel case for multiple words; for example,
doSomething
or doSomethingElse
. It’s not just the capitalization that’s important, though; you should also make sure that your code is as readable as possible, which means that method names should be expressive, but not too verbose.In addition, there are a few conventions that are required if you wish to take advantage of language or framework features. Property accessor methods, for example, must follow strict naming conventions in order to work with technologies like Key-Value Coding (KVC) or Key-Value Observing (KVO).
Relevant Chapters:Conventions
Prerequisites
If you are new to OS X or iOS development, you should read through Start Developing iOS Apps Today (Retired) or Start Developing Mac Apps Today before reading this document, to get a general overview of the application development process for iOS and OS X. Additionally, you should become familiar with Xcode before trying to follow the exercises at the end of most chapters in this document. Xcode is the IDE used to build apps for iOS and OS X; you’ll use it to write your code, design your app's user interface, test your application, and debug any problems.
Although it’s preferable to have some familiarity with C or one of the C-based languages such as Java or C#, this document does include inline examples of basic C language features such as flow control statements. If you have knowledge of another higher-level programming language, such as Ruby or Python, you should be able to follow the content.
Reasonable coverage is given to general object-oriented programming principles, particularly as they apply in the context of Objective-C, but it is assumed that you have at least a minimal familiarity with basic object-oriented concepts. If you’re not familiar with these concepts, you should read the relevant chapters in Concepts in Objective-C Programming.
See Also
The content in this document applies to Xcode 4.4 or later and assumes you are targeting either OS X v10.7 or later, or iOS 5 or later. For more information about Xcode, see Xcode Overview. For information on language feature availability, see Objective-C Feature Availability Index.
Objective-C apps use reference counting to determine the lifetime of objects. For the most part, the Automatic Reference Counting (ARC) feature of the compiler takes care of this for you. If you are unable to take advantage of ARC, or need to convert or maintain legacy code that manages an object’s memory manually, you should read Advanced Memory Management Programming Guide.
In addition to the compiler, the Objective-C language uses a runtime system to enable its dynamic and object-oriented features. Although you don’t usually need to worry about how Objective-C “works,” it’s possible to interact directly with this runtime system, as described by Objective-C Runtime Programming Guide and Objective-C Runtime Reference.
Copyright © 2014 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2014-09-17
Home > Articles > Home & Office Computing > Mac OS X
Page 1 of 1
Erik Buck, author of Cocoa Design Patterns, talks with David Chisnall about the history of modern Apple development from it's NeXTSTEP beginnings to Cocoa and Objective-C today.
Like this article? We recommend Cocoa Design Patterns
Like this article? We recommend
Like this article? We recommend
Erik Buck is the co-author of Cocoa Design Patterns and a long-time Objective-C programmer. I talked to him about how he's seen the Cocoa platform evolve from OpenStep, and where he sees it going in the future.
Although OS X is relatively new, it is built on top of technology that has been under development since Steve Jobs founded NeXT in the mid '80s. Erik has been working with this platform for over two decades, and for several years ran a successful software company developing software for NeXT machines. His perspective on the development of Cocoa, from its beginnings in NeXTSTEP and its evolution through the OpenStep specification, provide some interesting insights.
David Chisnall: What caused you to learn Objective-C originally? Was it very different to other languages you knew at the time, and what features of the language did you like the most?
![Cocoa Cocoa](/uploads/1/2/6/3/126391539/825140863.png)
Erik Buck: I saw a demonstration of the original NeXT Cube (http://en.wikipedia.org/wiki/NeXT) computer in late 1988 when I was a student at the University of Dayton. I was captivated and later drove to play with Cubes in Cincinnati and the Ohio State University in Columbus. The original NeXT demonstration applications included digital signal processing for sound and Display Postscript for graphics.
Believe it or not, the price was right too. For $7500 with a student discount, I got a much more capable NeXT system at a fraction of the price of a Mac II or any of the popular Unix workstations from the time.
At about the same time, I attended a seminar on ATT's 'C with Classes,' a.k.a. C++, which introduced me to object-oriented programming. I remember wondering at the time 'what was the big deal?' I managed to avoid really understanding Objective-C for at least a couple of years. I primarily wrote code in C using the Unix APIs, and I ported a lot of assembly language software originally written for the Atari ST computer. However, there was no way to avoid the heart of NeXTstep: Interface Builder and the various Objective-C frameworks including AppKit. NeXTstep became Mac OS X and Cocoa. Interface Builder and AppKit a.k.a. Application Kit Framework remain.
My first projects with Objective-C included writing a Tetris clone because my roommate derided any computer that didn't have a Tetris game. I confounded my college professors by turning in assignments written in Objective-C, but they were very supportive in the end. Objective-C grew on me gradually, and I appreciated the ability to mix procedural C code, functional Postscript code, and object-oriented code all in the same source file. I learned the NeXT frameworks from the documentation and the excellent book, NeXTSTEP Programming: STEP ONE: Object-Oriented Applications by Simson Garfinkel and Michael K. Mahoney.
The NeXT programming community was very tight-knit in the early 90s. It was not only possible but likely that you would meet the key developers both inside and outside NeXT. I was inspired by people like Andrew Stone of Stone Design (http://www.stone.com/New.html) and Jonathan Schwartz of Lighthouse Design (http://en.wikipedia.org/wiki/Lighthouse_Design). There were numerous NeXT related start-up companies and a wealth of excellent third party software. The excitement was contagious. NeXTstep and Objective-C were inspiring innovative new applications like WorldWideWeb (http://www.w3.org/People/Berners-Lee/WorldWideWeb.html), Lotus Improv (http://simson.net/clips/1991/91.NW.Improv.html), Diagram!, and Tailor (http://www.blackholeinc.com/catalog/software/Software/Graphics/Tailor.shtml).
Obviously, I had to start a company too. My company, EMB & Associates Inc., produced NeXTstep based design software for aerospace. The easiest way to describe our application was 'Interface Builder for aircraft cockpits.' Pictures of our application and its results appeared on the cover of nearly every aerospace magazine. We sold most of our intellectual property to a Fortune 500 company in 1996. The company continued for several years dabbling in the computer game industry before closing in 2002. I currently work as a Product Line Manager and Senior Staff for a different large aerospace company.
Tim Berners Lee once commented that his pioneering WorldWideWeb application was only feasible at the time because of NeXTstep. That was certainly true for my company's application. There were two failed attempts to port our application to Java, and each of the attempts likely cost more than the original development.
DC: I think you're the only person I've spoken to who liked the PostScript part of programming on NeXT. What kind of thing did embedding PostScript in your code make easy and what do you do on OS X, where Display PostScript is not present?
EB: Display Postscript provided a resolution independent What You See Is What You Get (WYSIWYG) display system with floating point coordinates and alpha channel transparency at a time when integer based VGA graphics were an extra-cost upgrade for competing systems. Apple has preserved and enhanced the Postscript imaging model with Quartz's implementation of display PDF.
Display Postscript provided a client server graphics model with stored procedures on the server. That provided several advantages that are only slowly coming back to MAC OS X. The most obvious feature lost with the transition to Quartz was remote display. It used to be common to display the output of an application on a different computer than the one running the application. The capabilities of stored procedures are coming back in different forms. For example, the Core Imaging model uses stored programatic 'filters' that execute asynchronously on the graphics processor. Postscript programs were like Core Image filters for 2D vector graphics. They allowed external parametric inputs to drive potentially complex rendering tasks that were performed asynchronously by a remote processor. Think Quartz Composer for vector graphics. In some respects, Tailor.app was Quartz Composer for Postscript graphics.
Postscript was a 'Turing complete' programming language that allowed arbitrary computation on a 'graphics processor' in the same way that current trends toward General Purpose GPUs are allowing arbitrary computation on a graphics processor (http://gpgpu.org/). Modern Quartz Extreme tries to offload more and more work to asynchronous processing by the graphics subsystem as enabled by Apple's announced 'Grand Central' parallel processing technology.
I like Quartz very much, and I appreciate many of the enhancements like standard antialiasing that have been provided as the PDF imaging model has advanced beyond Postscript. Display Postscript, like Cocoa, was far ahead of its time.
DC: How much of the structure of Cocoa do you think comes from the language and how much would be the same if OpenStep had been designed for, say, Java or C++?
EB: Object-oriented programming languages fall into two major categories: those inspired by Simula and those inspired by Smalltalk. The term 'object-oriented' was coined by Alan Kay, the creator of Smalltalk, but he later regretted the term. Languages inspired by Smalltalk are actually 'message-oriented' because the distinguishing feature of Smalltalk style languages is the ability to send messages to anonymous receivers.
C++ is a language that grafts Simula-style object orientation onto the C programming language while simultaneously trying to improve C. Objective-C is a language that grafts Smalltalk style message sending onto C while preserving the base C language unchanged. Both languages started from C because they wanted to preserve the world's investment in billions of lines of C code while providing a more productive path to the future.
Java was partly inspired by Objective-C. For example, Java 'interfaces' reused the idea of Objective C 'protocols.' Java and C# use C++ like syntax but abandoned C semantics in favor of protected virtual machines.
Learn Objective-c On The Mac Pdf
In theory, Cocoa could have been written in C++ or Java. In practice, the message-oriented nature of Objective-C is what makes Cocoa feasible and so amazingly productive. Qt Software/Trolltech's Qt framework is the closest thing you will find to a C++ re-imagining of Cocoa. Qt uses C++ with several non-standard extensions implemented by an additional pre-processor. The pre-processor is necessary to enable Objective-C like expressiveness and defines a messaging like capability.
To my eye, Microsoft's C# .NET Framework is becoming very Cocoa like. Microsoft has finally embraced the Model View Controller design pattern that is ubiquitous in Cocoa. The C# language is evolving to be closer in concept to Objective-C.
There is no better argument in favor of the trade-offs provided by Objective C than the elegance of Cocoa. Seamlessly use C. Provide easy bridges to other dynamic languages like Python and Ruby. Network distributed messages use identical syntax to local messages. I would argue that Cocoa would be much less elegant if it were implemented in another language.
DC: A lot of the original Gang of Four design patterns came from Smalltalk-80, which was also the inspiration for Objective-C and a lot of Cocoa. Can you give some examples of patterns that are unique to OpenStep / Cocoa?
EB: The Gang of Four frequently cite examples of their patterns not only in Smalltalk but in NeXTstep. Design patterns are intended to be reusable solutions to recurring problems. As a result, patterns are seldom unique to any one technology. The patterns in Cocoa can be found in other frameworks. However, the Objective-C language makes many of the original Gang of Four design patterns trivial or unnecessary.
Learn Objective C Pdf
The goal of object-oriented programming is to maximize programmer productivity by reducing lifetime software development and maintenance costs. The principal technique used to achieve the goal is object reuse. Design patterns identify successful strategies for achieving reuse on a larger scale than individual objects.
Cocoa Dev Central Learn Objective C Free
The principal obstacle to reuse is coupling. Coupling refers to dependencies between objects. Whenever such dependencies exist, they reduce opportunities for reusing the objects independently. All of the Cocoa design patterns exist in part to limit or avoid coupling. Objective-C helps to minimize coupling by allowing dynamic typing, messages to anonymous receivers, heterogeneous containers, message forwarding, and in Objective-C 2.0, properties.
The consistency with which Cocoa applies patterns is astonishing and contributes to legendary high programmer productivity. Ironically, the same consistency is a barrier to getting started. You can't take Cocoa's patterns a la cart. They are all interrelated, and if you don't understand a key pattern it will impede everything you attempt. You just can't get started without understanding Delegates, and then you can't use Delegates effectively until understand the Responder Chain which leads you to Hierarchies and Targets and Actions.
DC: You mentioned that some patterns are made unnecessary by Objective-C. The one that springs to my mind is the command pattern, since every Objective-C message send is an equivalent of this. Can you give some other examples?
EB: Objective-C selectors and messaging largely eliminate the need for the Command design pattern, but Cocoa's NSInvocation class still provides a concrete implementation of the command pattern. The command pattern is used by other frameworks to provide target/action like capabilities and to support features like scripting, undo, and redo that are all almost automatic with no code when you use Cocoa.
I think all of the famous GoF patterns exist within Cocoa, but many are either trivially implemented or made less necessary thanks to Objective-C. For example, the Cocoa convention of two stage allocation and initialization makes the GoF Abstract factory and Builder patterns trivial. Cocoa's Responder Chain was the inspiration for the GoF Chain of Responsibility pattern, but Cocoa's implementation is greatly simplified by Objective-C and the language's built in support for Command pattern capabilities and introspection like -respondsToSelector:.
DC: The question for every Objective-C 2 programmer: what do you think of the dot syntax for property accessors? Love it, hate it, or totally ambivalent to it?
EB: I agree with Aaron Hillegass that dot syntax is 'silly.' I think it's even a little harmful because it masks the crucial message sending that is really happening under the surface and provides the real power and flexibility of the language. When I glance at code, I want to see the messages, and dot syntax obfuscates the messaging.
Having said that, the dot syntax is a very small addition to the language. I don't want to blow it out of proportion. The related properties syntax is a great addition to the language. Properties allow additional expressiveness and communication of usage and intent in object interfaces.
DC: Objective-C 2 introduced a lot of small changes, and a couple of large ones. What are your favourites, and are there any you don't like?
EB: I like the properties syntax in Objective-C 2.0. A single @property declaration eliminates two method declarations that would otherwise be needed while simultaneously expressing intention/usage information than would otherwise have to be provided in comments/documentation. Coupled with @synthesize used in class implementations, the properties syntax reduces the amount of code I write. As Steve Jobs once said, 'the least expensive, most bug-free line of code is the one you didn't have to write.'
Properties also provide language level formalization of framework conventions like method naming for Key Value Coding. I think properties syntax points the direction toward even more language level dynamic behavior.
DC: Would you recommend Cocoa and Objective-C to someone thinking about learning to program? If not, what language and environment would you suggest?
EB: I think the C subset of Objective-C is the hardest part to teach someone who is just learning to program. I have taught Objective-C and Cocoa to many experienced programmers, and I am currently teaching my 14 year old son to program. I think Python is a great teaching language because is allows the student to achieve interesting results very quickly and postpones the need to explore more advanced concepts. Mac OS X's Python/Objective-C bridge, PyObjC, lets Python programmers enjoy Cocoa with a minimum of fuss.
My son and I have had fun playing with the excellent and free F-Script (http://www.fscript.org/) The tutorials, 'Exploring Cocoa with F-Script' and 'Learn F-Script in 20 Minutes and Have Fun Playing with Core Image,' are a great way to introduce a novice to Cocoa.
DC: Coming from a NeXT background, did you ever investigate the GNUstep project for porting your code elsewhere?
EB: I have used GNUstep for several personal projects over the years. I have also used Cocotron (http://www.cocotron.org/). I own a 3D game engine that was written in Objective-C during the dark period after Apple killed Objective-C++ and before Apple resurrected it. I achieved cross platform support by using my own pre-processor that translated Objective-C into a subset of C++ and used a runtime that was written in C++. This allowed easy intermixing of Objective-C and C++ that enabled proper behavior when C++ objects were used as Objective-C instance variables etc. I never did get C++ exceptions with stack unrolling to work right though. Several years ago, I used my tool chain to translate/recompile most of GNUstep. The result was some truly ugly C++ code that nevertheless compiled and ran on nearly any Unix system that has a C++ compiler.
I have supplied flex/bison based Objective-C scanners/parsers to many people over the years, but I don't know if or how they were ever used. I am currently fascinated by the possibilities of LLVM (http://llvm.org/).
DC: What projects are you currently working on?
EB: Like everyone else, I have an iPhone game in the works as a hobby project. The game has had a long history with on-again off-again publishing contracts for a Windows version. Right now, it looks like it will be self-published, and the iPhone and Mac OS X desktop versions will be the first or only places it ships. The iPhone App store is a revolution for software distribution. It has the potential to eliminate brick and mortar software sales. If/when that happens, what role will game publishers have? Even now, game publishers exist almost solely to lend money, generate publicity, and rent shelf space.
DC: What future directions do you see for Cocoa?
I expect the forthcoming Mac OS X Snow Leopard to set a new high standard for performance on multi-core computers. I predict that Cocoa will see huge performance enhancements in areas like text layout, spotlight, and multimedia thanks to Grand Central and Apple's fantastic developer/profiling tools including compiler improvements.
Learn Objective C Free
Related Resources
- Book $35.99
- Book $39.99
- eBook (Watermarked) $31.99