tonyarnold.com

Private methods in Objective-C using categories

Tue, 04 May 2010 01:15:00 +1000

Objective-C is an incredibly flexible language, but there are a few things I don’t think it handles very elegantly — private methods are one of those things. Private methods are important when designing your classes — keeping the implementation of your methods separate to the interface that users of your class see is good practice, and lets you change the way you implement things in future without making users of your class change their code.

Objective-C has a great feature known as categories. In the words of Scott Stevenson, “a category allows you to add methods to an existing class without subclassing it or needing to know any of the details of how it’s implemented”. My private methods are implemented using an anonymous category on each class. These are also known as “Class Extensions” and they look like this in my .m file:

#import "MyGreatClass.h"

@interface MyGreatClass ()
- (void)MyGreatClass_somePrivateMethod;
@end

#pragma mark -
@implementation MyGreatClass

// Your standard methods for the class go here.

#pragma mark -
#pragma mark Private methods
- (void)MyGreatClass_somePrivateMethod {
  // Implement your private method here.
}

@end

By declaring the method interface inside the class extension, rather than in your header, subclasses and users of your class cannot see the method, and thus can’t use it. However within an instance of your class, the method is still usable!

You’ll notice that I preface my private methods with the name of the current class — I do this to avoid method name collisions with subclasses. It’s not strictly necessary, but it means I don’t have to think as hard when implementing subclasses of my class.

You can do everything you would in a normal class except declare new instance variables. I often use my class extensions to redeclare a public readonly property as readwrite within the confines of the class instance. Another common use in my code are the following two methods:

- (void)MyGreatClass_registerObservers;
- (void)MyGreatClass_unregisterObservers;

These methods are used to set up and tear down any Key/Value Observers and bindings for the current class. I use these so often that I’ve put together an Xcode class template so that they are included in my classes by default.

Please keep in mind that Objective-C has no true implementation of private methods — other classes can use these “private” methods if they know the structure of the method in question. With that said, I still believe this is a great way to keep your implementation as clean as possible.

Update

Both Paul and Collin make good points in the comments — you can just declare your private methods inline in your class without using an anonymous category. That will work so long as the declaration occurs before the first use of the method. In my mind, there are two good reasons to use a category:

Readability/cleanliness — I find it a lot easier to group the declarations for my private methods together inside the category block. It’s quite readable and means I can just look at the start of the source for each of my classes to see what private methods are defined;
It’s the same when compiled — as I understand it, anonymous categories are compiled into the same space as the methods for the class they are defined for. Functionally — once the code is compiled — there shouldn’t be any difference between the two ways of defining the methods.

WWDC 2010: the death of the Mac (or not)

Mon, 03 May 2010 02:11:00 +1000

It appears that Apple’s World Wide Developer’s Conference (WWDC) is about iPhoneOS 4.0 this year. The focus of the advertising, the sessions and the announcements all appear to be firmly focused on iPhone and iPad development, and there’s scarce mention of the Mac in amongst the copy. This in and of itself is fine — the focus of the last 2 years (2008−2009) was pretty clearly on Mac OS X “Snow Leopard”, so given the impending release of a major operating system release for the iPhone (and eventually iPad) I can understand why they’d be focusing on their new baby.

But it’s raised a bit of an irate response from the more Mac-focused developers — “What about me?”. At first, I was incensed too — why would I want to pay close to $6000 AUD for tickets, flights, accommodation and food to go to a conference that’s taken the focus off my primary development platform? I get it, though — it makes sense. And yeah, I’d get some benefit from the iPhone OS sessions. However, I’m pretty certain that I wouldn’t get $6000 worth of benefit this year, so I’m putting my hard earned money to one side for this year in the hopes that WWDC 2011 is a better fit for my needs. As are a number of other high profile Mac developers (who I was really looking forward to catching up with, you bastards!). But that’s OK — there are more iPhoneOS developers than there are Mac developers these days anyway so WWDC will still sell out and the planet will continue to turn.

The only part I don’t understand is taking the Apple Design Awards away from Mac developers, but then the iPhone OS-based ADAs this year are a locked down shadow of what the ADAs used to be, so I don’t think I’ll waste too many words on this except to say that outwardly it’s a pretty shitty move from Apple. My oft-unused rational brain says that 5 weeks for ADA submissions and selection for both platforms seems a little tight, but all of the WWDC material feels rushed and unfinished this year. It’s as good an excuse in my brain as any.

My opinion is that next year’s WWDC will have a greater focus on whatever future version of Mac OS X Apple are working on — let’s call it “Mac OS X 10.7″ for the rest of this post, understanding that it might be called “Cecil”, or something far less interesting when it actually comes out. The design awards will have a Mac category again, and we’ll all get excited about what’s coming next.

You know what really grinds my gears?

So here’s the bit that’s annoying me: there is a vocal contingent of Cocoa developers who are saying loud and proud that the iPhone and iPad are the future of computing, and that developers should be shifting their business and efforts to these platforms (and subsequently away from the Mac). Just sit back and think about this for a minute — if you were forced to use just your iPhone or iPad to do everything you do now, could you do it?

I’m not Joe Average, but I certainly couldn’t.

There are plenty of things I can (and do) get away with on my iPhone 3GS — basic emailing, basic browsing, simple task management, etc. You’ll pry the damned thing from my cold, dead hands. But I can’t get real, honest-to-god work done on my iPhone without serious impact to my time and productivity (I also can’t use Xcode, so that’s going to stop me right there — but let’s ignore that for now).

It’s about style, baby

Before I begin: I’m purposely leaving games out of this argument — this is about replacing my desktop computer, and I don’t use my desktop computer for games.

The style of applications on the iPhone and iPad are usually simpler, cut-down versions of their desktop cousins — there’s only a few apps I can think of that have feature parity with their desktop counterparts. Tweetie and Twitteriffic are examples that come to mind (although arguably their desktop versions have been left to die for the past year). I’ve not used the iPad-based iWork suite yet — which I’d pinned high hopes on — but the reviews are pretty clear that these are not complete replacements for iWork on the desktop. I also don’t see a full replacement for iPhoto, GarageBand or any of Apple’s consumer apps. In fact, there’s very little in the way of rich content creation.

I expect that the larger screen and differing user interface on the iPad will go some of the way toward addressing this issue in time, but the iPhone is unlikely to offer as rich or productive an experience as a well developed, fully-featured desktop application. Prettier? Yeah, sure — maybe. More fun? Perhaps — there are some great iPhone apps out there. But genuine, get work done all day long every day apps? Not yet. Not by a long shot.

Innovation? Where?

One of the key arguments being used is that there appears to be a lack of innovation on the desktop lately. I’d argue there’s little real innovation occurring on either side of the fence.

That’s not saying that there aren’t some really cool apps being developed. Wrappers around oft-used sites that are infinitely more usable than the original site. Quick methods of letting your friends know how banal your existence is by using your location. Nifty ways to tune my guitar.

There have been some real interaction improvements based upon the touch-based user interface — “pull down to refresh” in Tweetie is one of them. But take the whole “I can use my fingers” thing off the table (and I’m genuinely interested in an answer to this question) — what exactly are these wonderful innovations being bandied about on the touch platforms? Touch itself? That’s been around for years in similar (albeit poorly implemented) forms. I do want to know, because I’m still seeing user interface conventions like tableviews and drawers from 2005, gussied up with some iPhone make-up.

You’re just a hater, silly old-time developer!

I assure you: I most definitely am not (a hater, or old — although I do have a few grey hairs in my beard that weren’t there last year). I love my iPhone. I’ll buy an iPad when they’re available here in Australia. I am, do and will continue to develop apps for the iPhone OS — it’s a marvellous, groundbreaking piece of technology.

I also agree with the basic sentiment being expressed — input other than physical keyboards and mice will eventually take over for standard interaction with our computers. I also think the iPad is a glimpse at something wonderful. But it’s a glimpse, not the whole picture. I’m also not surprised by the noise coming from the iPhone OS camp — it’s new, it’s shiny and there are (some) people making an absolutely killing off the sales of their apps. Some of those apps are actually genuine leaps forward in terms of using the new interaction models that Apple’s designed for the iPhone.

But in my opinion, it’s not the end of the desktop or the Mac.

Fin?

I believe the Mac has a heck of a lot of life left in it. Will the fun end some day? Sure. Will it be brought about by iPhone OS — no, I genuinely believe it won’t. When there’s something better to replace everything we use our Macs for now, I’m sure Apple will retire the mantle. Until then, we’ll have divergent technologies with differing purposes.

Yep, I’m biased — I love developing for the Mac, so I’ll still be at it even when I have award winning, billion-dollar-a-year apps in the app store (heh).

Am I done? Not quite. “One last thing” as the saying goes:

My message to the “Mac is dead” crowd — have the foresight to preface your statements with “in my opinion”. It’s less inflammatory than stating your opinion as if it were fact, and you won’t feel quite so bad when it doesn’t happen. Wait, that wouldn’t draw attention to your iPhone apps, would it? #waitiseewhatyoudidthere

Now, go look at my Mac apps. Fin.

Making your iPhone app’s maps work like Apple’s

Wed, 21 Apr 2010 17:35:00 +1000

Disclaimer: These instructions have been tested under iPhone SDK 3.1 — they will probably work under future releases of the iPhone OS, but I don’t make any guarantees. Don’t ever blindly include code in your apps.

I’ve had the opportunity to work on a couple of smaller iPhone apps that include MKMapView components to show the location of stores and other items of interest. One of the things I found a little challenging was that the map views didn’t work quite the same way as those found within Apple’s Maps.app on the iPhone. I mean, sure — you can pan around the map with your fingers and zoom in and out by pinching, so the basics are there — but once you start tracking the user’s current location (showsUserLocation) all the nice stuff just falls away.

Try it now — pop open the Maps app on your iPhone and tap the little crosshair button in the lower left corner of the map to show your current location. Straight away you’ll notice that the map zooms and scrolls to centre on your current location. Now try moving the map around — the map location follows your fingers, with that pretty blue pulsing dot tailing your every move. Nice, huh? OK, now scroll the map somewhere else using your fingers. What happened? The showsUserLocation property just set itself to NO and the map stopped following you. Right thing to do, hey? Guess what — that’s not standard behaviour if you just drop an MKMapView into your app. The good news is that it’s not hard to copy this behaviour, and you don’t have to use private APIs either (nice!).

Here’s how an MKMapView is structured at the highest levels (in a very loose sense):

MKMapView
- UIView
  - UIScrollView

And that’s what makes it nice and easy to replicate this behaviour — the UIScrollView has a property named contentOffset that we can watch for changes using Key/Value Observation. When the contentOffset property changes, we can quickly check if the user is making the changes (in which case we want to turn off our showsUserLocation property), or if something else like the application is making the changes in which case we just want to ignore the change (ie. when zooming to a specific pin due to a search).

Sample Code

I’ve uploaded a sample project to Github containing a very simple implementation of this approach — you’re welcome to clone it, fork it or just read through it:

TapThatMap Sample for iPhone SDK

Hopefully this will help someone else looking to achieve the same effect. Currently, tapping the “Start Following Me” button does not zoom to and centre on the user’s location like Apple’s Maps.app, but otherwise the functionality provided by MapKit.framework should be enough. I’ll add more to the sample project as I get time.

Campaign Monitor from within your Cocoa app

Wed, 13 Jan 2010 16:09:00 +1000

This is the first of my ‘Giving back’ posts. The idea is that I’ll give something back to this wonderful Cocoa coding community at least once every couple of weeks. I mean, what’s the point of going indie if I can’t do what I want once in a while? :)

Of all the marketing avenues I continue to investigate and read about, mailing lists seem to be something that the rest of you recommend time and again. I missed a few boats when I launched Hyperspaces — were I to do the launch over again, I’d make sure that a mailing list was in place and easy to join from my website and within my app. I’ve always admired the way the Panic apps ask you to join their mailing list the first time you start them — it’s simple and unobtrusive.

As part of my work toward future versions of Hyperspaces, I’m looking to do the same. I’m still deciding which mailing list package/provider I will use in the end, so please don’t take this as a “this is what The CocoaBots use” post, however I did meet the Campaign Monitor guys at Web Directions South 09, and their product has a nice web service API. So I put together a small example project that will sign a user up to your Campaign Monitor mailing list from directly within your app.

The code is heavily inspired by Uli’s UKCrashReporter and Wolf’s JRFeedbackProvider projects (this is like a mutant offspring of the two). I may not end up using it in my apps, but hopefully someone else finds it useful.

The GitHub project is at http://github.com/tonyarnold/CBMailingListSignup, and the code is licensed under the Creative Commons Attribution 2.5 Australia License.

Hyperspaces 1.0 and The CocoaBots

Tue, 15 Dec 2009 12:42:00 +1000

There’s more about this over at the new CocoaBots blog, but I just launched Hyperspaces 1.0. Further to that, The CocoaBots is now a full-time venture — check out the new site for more info!

I’ll put together a post about going indie soon (I promise!) but for now all I can say is that I love it!

Core Animation uses a lot of memory

Sun, 23 Aug 2009 22:22:00 +1000

Here’s something Apple should probably put on the box when they sell Core Animation to new developers: It uses a lot of RAM. Before you dive in with both feet, you need to ask whether the features you get from Core Animation will really be worth the overhead.

In Hyperspaces, if you’re running on a single monitor set-up, you’ll generally see RAM usage around the 60-100Mb mark (RSIZE). Two screens, you’re going straight beyond the 100Mb mark. I assume it grows exponentially from there, but I’ve no machines on hand that will drive more than 2 screens (Update: I assume wrong — the caching is pretty good for CGImageRefs and their ilk. It won’t grow exponentially).

On a single monitor set-up, there are two layer-backed views — one screen-size view that sits behind your desktop icons, and one smaller view that contains the switcher. If I run up Hyperspaces without either of my layer-backed views enabled, the application uses 13Mb RAM — so the core (for what it does) is quite compact. If I re-enable the layer-backed switcher window, memory usage instantly jumps to 56Mb — the switcher is usually about 500 — 600px wide, and about 100px high (with 3 spaces enabled).

I have spent months trying to bring this number down by any means possible. So far, I’ve tried:

Cropping and chopping my CGImageRef objects down to only exactly what’s needed for display;
Aggressively caching and uncaching CGImageRef objects (thanks go out to Sean O’Brien for helping me with that);
Storing only the CGImageSourceRef for each of my images and explicitly telling those sources not to cache their CGImageRefs;
Saving those cropped and chopped CGImageRef objects out to cached JPEG2000 files and then reading those files back into cached NSData objects to be decoded when needed;

There are probably other things I’ve tried that have worked to varying degrees, but those items above are the ones that made a difference. They don’t solve the problem.

If you’re writing a background application that you expect your users to have open all the time, you (unfortunately) will need to think very carefully about whether you should use Core Animation in your application. I’ve had feedback from users of Hyperspaces that they would prefer to leave the animation in — while I pitch Hyperspaces as a tool that provides context to Apple’s Spaces, I’m pretty sure a lot of the users are more into the eye candy and the softly fading desktop images :)

I’ve certainly asked for advice about this issue in a few different places, as well as done my research — and I’d be very happy to be proven wrong (please?!).

Get Satisfaction for user support — does it work?

Thu, 16 Jul 2009 22:17:00 +1000

For the past few months, I’ve been using the free version of Get Satisfaction to manage end-user support for Hyperspaces, and I thought it was time to write a bit of a retrospective. I want to start by saying that I don’t think there is a perfect answer to user support — people are funny creatures, and they tend to want help on their own terms. This usually means that a tool like Redmine (which I absolutely love for my development and product testing) is going to annoy the hell out of your Mum & Pop software users (what’s a ‘milestone’, and why do I care?).

I’ve been through a few different products over the years, including Sourceforge, Trac and Redmine — all of which were and are brilliant, but far too focused on development. Finally, around 12 months ago, I started looking elsewhere for my user support — “Surely there’s something better!” I told myself. Thankfully, there was: Get Satisfaction. From Wikipedia’s description of Get Satisfaction:

The company describes its product as “people-powered customer service”. On the website, anyone can ask a question, submit an idea or complaint, or give praise; all posts can be read by anyone. Companies can respond to issues regarding their products or services; official responses are marked as official answers to separate them from other responses. Users can rate responses based on how well they resolve the issue.

I started seriously looking at Get Satisfaction around May last year, and at the time I was very impressed. When I publicly launched Hyperspaces earlier this year, there was a Get Satisfaction page for it on launch day.

And for a time, it was great — I’m a big believer in being hands on and communicative. If there’s a problem with my product, I take care to publicly acknowledge that I’ve got the message even if I have no idea how to fix it yet. I did that — I answered, and answered and answered. I think my users appreciated it. w00t!

Then the clouds started to form.

With more questions being posted, the page started getting really messy, and I honestly believe quite hard to use. The interface now seemed cluttered and obstructive rather than helpful, and I was getting lots of duplicate questions — “this isn’t working how it’s supposed to”. I’m a developer, not a user of my product, so I don’t pretend that I always know what mine are thinking, but surely this wasn’t an easy way to get an answer to your question?

I am at the point now where I am seriously reviewing other options for user support. The problem is, I’m yet to find something that’s as simple — and more importantly, free — as Get Satisfaction. entp’s Tender looks really, really nice — but it’s expensive for me.

To complicate matters further, Get Satisfaction has just released version 2.0 of their site. The company overview is now a fantastic layout — nice, simple and straight-forward. It’s categorised and visually sorted. The product pages aren’t so lucky — they’re still a formless mess, and I have a hard time understanding why there’s not some structure to them.

Company Overview

Product Support

I’ll keep this post updated with what I decide to do, but right now I’m seriously weighing up whether it’s worth pouring some of the money I’ve made from Hyperspaces into a really good support package from somewhere like entp.

Testing testers

Thu, 02 Jul 2009 21:01:00 +1000

One of the challenges most independent developers will face is finding good testers for their applications. I’ve been relatively lucky with Hyperspaces — my users tend to take the time to tell me what’s going on when they submit a crash report, or start a new conversation on GetSatisfaction. What I have had troubles with is finding enough people willing to help test upcoming releases — right now, I have a great new release of Hyperspaces ready for a few keen souls to try out, but nobody has downloaded it! If you’re a user — please — give it a go, let me know what you find. If you’re a developer, read on…

So what do other independent developers do in this situation? My tests (unit and functional) tell me that the release is OK, but after some earlier mishaps I’m much more cautious about just throwing out a new update via Sparkle. I don’t have the money to spend on hordes of formal testers, and I’m pretty sure people do actually use and love my app — is it right to harness that goodwill for my testing purposes? Or should I just be saving up to pay some testers? What’s a reasonable amount? Questions, questions, questions…

CATiledLayers are fun

Sat, 04 Apr 2009 01:03:00 +1000

One of the big issues I’m trying to address for Hyperspaces 1.0 is related to video memory:

Core Animation likes to cache any imagery you insert into a layer onto the user’s graphics card, which is fantastic when you’re running on a machine with more than 256Mb VRAM — things are smooth as silk and you get great fades between changes. Unfortunately, for users running on Macs that don’t have that much VRAM there is a big problem — if the image you load into the layer is too big to fit into VRAM, Core Animation just doesn’t draw it. White backgrounds for the win.

Apple’s answer to this problem is the CATiledLayer. Basically, it allows you divide a much larger image into smaller chunks that can be cached on older video cards. For Hyperspaces, I’m working on replicating the drawing styles of the standard Mac OS X desktop background — “Fit To Screen”, “Fill Screen”, “Stretch To Fill Screen”, “Center” and “Tile”. Tiled desktops are fine — I’m rendering those using a CATiledLayer in the build you’re all using right now (1.0fc4).

What’s interesting though is what happens when I play lazy programmer:

Lovely, no? It would be a cool effect with a longer fade, and if I weren’t already getting complaints about how slow Hyperspaces is to change desktop backgrounds right now. I’m still working on the final code — I’ll post it when it’s done for reference — but the simple answer to this problem is twofold:

Make the tiles as large as you can — this isn’t too tricky. Apple defaults this to 256px by 256px, but I haven’t done enough research to know what’s reasonable — it’s really going to be based upon your target audience, and whether they have decent graphics cards or not;
Cache the “sliced” image pieces — the video you see above is the result of me slicing a CGImageRef up in real time;

I hope you enjoy the (unintended) effect!

Me too, me too!

Sun, 15 Mar 2009 11:48:00 +1000

Filed under the most daring display of FUD and stopwatch timing this week: Microsoft’s own speed tests show IE beating Chrome, Firefox

Riiiiiight.