Showing entries tagged "cocoa". Full blog index
Our long effort to rebuild Cocoa piece by piece continues. For today, reader Nate Heagy has suggested building
Asserts are a powerful tool for building quality code, but they're often poorly understood. Today, I want to discuss the various options for writing asserts in Cocoa apps and the best ways to use them, a topic suggested by reader Ed Wynne.
It's time to take a turn to some lighter fare, but to a subject that's near and dear to my heart. The fundamental UI component of a Cocoa app is the NSWindow, and there are many different ways to instantiate and manage them, but there is only one correct way: for each type of window, there should be a separate nib file, and a specialized
NSWindowController subclass. I'll walk through what this means and how to do it, a topic suggested by reader Mike Shields.
Objective-C is a powerful and extremely useful language, but it's also a bit dangerous. For today's article, my colleague Chris Denter suggested that I talk about pitfalls in Objective-C and Cocoa, inspired by Cay S. Horstmann's article on C++ pitfalls
, I presented the implementation of a basic flood fill. That implementation works fine, but is not terribly fast. Today, I'm going to walk through various optimizations that can be done to make it faster, using techniques which I hope will be useful in many different situations. Ultimately, starting from the original code, I was able to achieve over an order of magnitude speedup while still keeping the code relatively straightforward and clear.
Following up from the previous article about manipulating image data
, Marc Palluat de Besset suggested a followup discussing the implementation of a flood fill. Today, I'm going to walk through the theory and practice of implementing flood fill on an
Cocoa provides some great abstractions for working with images.
NSImage lets you treat an image as an opaque blob that you can just draw where you want it. Core Image wraps a lot of image processing in an easy-to-use API that frees you from worrying about how individual pixels are represented. However, sometimes you really just want to get at the raw pixel data in code. Scott Luther suggested today's topic: fetching and manipulating that raw pixel data.
I'm back again for Friday Q&A, and this week I'm going to follow up on Mike's 2008 article, Key-Value Observing Done Right
, where he debuted a replacement for KVO,
. It's been a long time since then, and it was high time such a useful piece of code got an update, which I gave it. With the help of Mike and Tony Xiao
, it's gotten a full overhaul and is now a modern code library with some fun features. In this article, I'm going to go through the new stuff and how it was done.
Since the moment Apple announced it, readers have asked me to write about Automatic Reference Counting, or ARC. Today is the day. I'll talk about Apple's new memory management system, how it works, and how to get the most out of it.
Last time, I discussed how to build
NSAutoreleasePool and how it works internally. Today, I'm going to carry that theme forward by building an implementation of Cocoa reference counting with
release, a topic suggested by David Dunham.
It's that time again: time for more programming craziness. Dallas Brown suggested that I talk about how
NSAutoreleasePool works behind the scenes. I decided that the best way to do that would be to simply reimplement it, and that is what I'll discuss today.
Notifications in Cocoa are extremely useful and are pervasive in Cocoa programming. Unfortunately, a lot of Cocoa programmers see the notification system as something of a black box: a notification is posted, Stuff Happens, and somehow the observer gets notified. Fortunately, the Stuff that Happens is actually pretty simple, and to explore it, I'm going to reimplement an
NSNotificationCenter workalike from scratch to illustrate how it all works, a topic suggested by Dylan Copeland.
at 2010-09-04 21:51
My recent whining
about ridiculous moderation policies on
has borne fruit! Brent Simmons has graciously created
, a group dedicated to Cocoa discussion but without the foolishness. I've already joined, and I encourage you to do so as well. A well-trafficked mailing list where we can talk about Mac programming without minions of the Mothership getting in our way will be a wonderful resource to have.
Welcome back to another word-laden edition of Friday Q&A. About a year ago, I wrote a post on defensive programming
. That post covered defensive programming in a general sense, and Scott Gould has requested that I write one specific to various standard Cocoa practices, which is what I will be talking about today.
Welcome back to another frightening edition of Friday Q&A. This time around, friend and local OS X coder Jose Vazquez
has suggested that I discuss how to implement
in Objective-C classes.
Welcome back to a late edition of Friday Q&A. WWDC pushed the schedule back one week, but it's finally time for another one. This week, I'm going to discuss the implementation of equality and hashing in Cocoa, a topic suggested by Steven Degutis.
Welcome back to another edition of Friday Q&A. For this week's post, I'm going to talk about three somewhat obscure collections classes that were introduced to Cocoa in 10.5:
NSMapTable, a topic suggested by Phil Holland.
Reader Steven Degutis was inspired by my post about Distributed Objects
and decided to make something that avoided those pitfalls. The result is SocketObjC
, a remote messaging library that uses continuation passing style
to achieve full asynchronous messaging. I haven't tried it, but it's worth checking out
Welcome back to another Friday Q&A. This week, Quentin Carnicelli (who is heavily involved in generating my paychecks) has suggested that I talk about things that every Apple programmer should know. In other words, common Cocoa design and implementation decisions that I'd prefer Apple not to make.
Happy iPad 3G day to everyone. Whether you're waiting in line, waiting for the delivery guy, or just pining at home like I am, you can fill your idle moments with another edition of Friday Q&A. This week, Filip van der Meeren has suggested that I discuss retain cycles and how to deal with them.
Welcome to another chilling edition of Friday Q&A. While I hope to be soaring over the scenic Shenandoah Valley on this fine Friday, I have taken the precaution of preparing my post in advance, so that you may see it even while I am incommunicado. Such is the magic of the modern world. This week, Michael Crawford has suggested that I give in example of implementing a custom control in Cocoa.
It's that time of the week again. No, it's not just time to go get drunk, but time for Friday Q&A! This week's topic, suggested by Christopher Lloyd of Cocotron
(a really neat open source project that lets you write Objective-C/Cocoa code for non-Mac platforms like Windows), is
, a little-known, poorly-understood, but handy Foundation class.
It's the first Friday of the new year, and that means it's time for the first Friday Q&A of 2010. This week, I'm taking Dave DeLong's suggestion of talking about
It's Black Friday, and that means it's time for another Friday Q&A. Today I'm going to talk about the use of accessors in Objective-C init/dealloc methods, a topic suggested by Jon Trainer
It's another Friday and time for another Friday Q&A. This week, fellow Amoeba Jeff Johnson suggested talking about using Cocoa from the command line using Python and PyObjC.
It's another Friday, and so time for another Friday Q&A. This week, Quentin Carnicelli (one of the guys who signs my paychecks) suggested that I talk about dangerous API calls in Cocoa.
It's time for another Friday Q&A. I hope everyone who had a chance to go to C4 had a good time and is back home safe and sound. This week I'm going to discuss singletons, both how to make them and when to use them, as suggested by Jon Trainer.
Welcome back to another Friday Q&A. This week I'm going to take Erik's (no last name given) suggestion from my interprocess communication post
and expand a bit on Distributed Objects, what makes it so cool, and the problems that it has.
Greetings one and all. I caught my mistaken writing of "2008" in this blog post title almost instantly instead of only noticing after I'd already posted it like I did last week, so the year must be coming along. Welcome to the second Friday Q&A of 2009 (and only the fourth in all human history!) where I'll be taking Ed Wynne's suggestion and talking about the various meanings and implications of thread safety as they apply to Mac OS X system frameworks.
Cocoa's Key-Value Observing facilities are extremely powerful and useful. Unfortunately they have a really terrible API that's inherently broken in a couple of different ways. I want to discuss how it's broken, and a way to make it better.
One of the longest ongoing controversies in the Cocoa community is how to write your init methods. More specifically, how to properly call your superclass's initializer. In the hopes of putting this controversy to rest, I want to walk through the right way to write an initializer and exactly why this is the right way.
I finally got a chance to run my performance comparison code on an iPhone, so we can see just how much horsepower this little device has. I still am not able to load my own code onto the device myself, so I want to thank an anonymous benefactor for adapting my code to the new environment and gathering the results for me.
By popular demand, I have re-run my Performance Comparisons of Common Operations on the same hardware but running Leopard.
Leopard's been out for a while now and brings with it a lot of interesting new tools for the Mac programmer. I've had the chance to work with some of them and want to offer my opinion on how they've worked out.
The move to garbage collection in Cocoa has been interesting. People have said that it's impossible, or impractical, or a bad idea, or doomed to failure, and one of the most common things trotted out is that GC is inevitably slow. However, I think that enabling garbage collection in your Cocoa app could actually be a good way to increase performance under the right conditions.
We all know that premature optimization is the root of all evil. But a recent conversation brought to mind that we often don't really know the runtime costs of the code we write. While we should be writing foremost for correctness and clarity, having an idea of these speeds is good, especially when we get it into our heads that some operation is much more costly than it really is. With that in mind, I compiled a list of common Cocoa operations and how much time they require at runtime.
I just hit a subtle but commonly known bug for the first time. I thought I'd share my fun with the world.
Everybody reading this blog should know about autorelease pools and how they work in Cocoa. As everybody knows, every time you go through the event loop, Cocoa blows away the old pool and makes a new one for you, so that all of your autoreleased objects go away and your new ones go into a fresh pool. That way you never build up more objects than get produced during a single event loop cycle.
Using Evil for Good
at 2006-07-14 00:00
People who know me as a programmer probably know that I am a great hater of C++. As someone who does a lot of Cocoa, this extends naturally into hating Objective-C++. But I made good use of Objective-C++ in ChemicalBurn
and I thought I'd share.
Autorelease is Fast
at 2006-06-07 00:00
If you've done much Cocoa programming, you've probably run into a situation where you needed to create a local autorelease pool because of some sort of loop. And you've probably run into advice telling you not to create and destroy the pool for every iteration, because that would be slow. I never believed that it could be significant, and I finally took the time to test it today. What's the verdict? Just as I thought, making autorelease pools is really fast.
Cocoa SIMBL Plugins
at 2006-03-25 00:00
Occasionally, we wish our favorite programs would sport a particular feature that just isn't there. Those of us who aren't developers need to fall back on lobbying for features, but those of us fortunate enough to be in the biz, churning out line after line of Objective-C well into the heart of the night, waking up the next day with bloodshot eyes and feeling not unlike the living dead, have other options. O, we lucky few.
If you've done any OpenGL work in Cocoa, you may have noticed that OpenGL surfaces behave badly when it comes to things like miniaturization and deminiaturization to the Dock. This recently caused some big problems for me, and I finally found out how to get rid of these problems altogether. It wasn't excruciatingly hard to find, but I wanted to make a post about it here so that it could be found with words like "deminiaturization".