This should be a one-time event for existing accounts. I suspect that new accounts will not see it. The solution is to open www.pandora.com in Safari, answer the question, and then re-launch PB.

PandoraBoy goes directly to the the mini-player on launch. Pandora doesn’t code for that since it’s impossible from the website. So sometimes they make interfaces that are larger than the mini-player without updating the mini-player code to resize. PB doesn’t resize the window (it doesn’t know how large it should be). It just relies on the mini-player to do it in Javascript, but in cases like this, the mini-player also doesn’t know how large the window should be.

BTW, I often am asked why PB doesn’t make the window resizable for cases like this. The answer is that it doesn’t help. The mini-player is a flash app, and has a clipping frame independent of the window. So while you can resize the window, the content is still clipped at the border of the flash app. Ah, the wonders of Flash.

- (void)sendKeyPress:(int)keycode withModifier:(int)modifier
{
    ProcessSerialNumber psn;
    GetCurrentProcess(&psn);
    CGEventRef modifierEvent;
    if (modifier != 0)
    {
        modifierEvent = CGEventCreateKeyboardEvent(NULL, modifier, YES);
        CGEventPostToPSN(&psn, modifierEvent);
    }

    CGEventRef keyEvent = CGEventCreateKeyboardEvent(NULL, keycode, YES);
    CGEventPostToPSN(&psn, keyEvent);
    CGEventSetType(keyEvent, kCGEventKeyUp);
    CGEventPostToPSN(&psn, keyEvent);
    CFRelease(keyEvent);

    if (modifier != 0)
    {
        CGEventSetType(modifierEvent, kCGEventKeyUp);
        CGEventPostToPSN(&psn, modifierEvent);
        CFRelease(modifierEvent);
    }
}

First note the use of CGEventPostToPSN(). I originally made the mistake of using CGEventPost(). The problem is that this will send the keystroke to the currently active application, not PandoraBoy. For keyboard shortcuts and applescript where PB will certainly be in the background, CGEventPostToPSN() is a must here.

Note that this uses virtual keycodes. That’s fine for PB, since (for now) we only send things that are universal (like spacebar). But it will be a problem when I implement sending “z” to snooze a song. The problem is that “z” means “the location of ‘z’ on an ANSI keyboard.” If you have a different keyboard layout, it’s still going to act like you pressed that lower left-hand key beside the shift, not “z”. If people have trouble with this, I’ll look into UCKeyboardLayout, but it was too much for tonight, and I don’t need it myself.

The modifiers are tricky because if you want to send “Z” that really means “shift down, z down, z up, shift up.” This method takes care of all that for you. You would send “Z” like this:

[self sendKeyPress:kVK_ANSI_Z withModifier:kVK_Shift];

Sometimes you want to inject some logic into a method you don’t control. The most common sane reason to do this is for debugging or profiling. For instance, you might want to log every time the various NSNotificationCenter methods are called so you can determine if that’s a performance bottleneck. (As I discovered myself, if you have thousands of notification observations in your system, it can be a serious performance problem.)

In most OOP languages your only option would be to subclass the object you want to instrument and then arrange for every instance of that object to be your subclass. In many cases that’s either very difficult or outright impossible, particularly if the object is used internally by a system framework. But Objective-C is highly dynamic, and message dispatching is resolved at runtime. You can modify how it works.

On Mac, there is an NSObject method called poseAsClass: that can achieve this easily. Unfortunately, it’s deprecated in 10.5 and isn’t available at all for Mac 64-bit and iPhone. I want a technique that I can use reliably for all my platforms, and luckily there is a fully supported alternative: method_exchangeImplemenations().

So how do we use it? First, we create a category on our target (NSNotificationCenter):

@interface NSNotificationCenter (RNHijack)
+ (void)hijack;
@end

@implementation NSNotificationCenter (RNHijack)
+ (void)hijackSelector:(SEL)originalSelector withSelector:(SEL)newSelector
{
    Class class = [NSNotificationCenter class];
    Method originalMethod = class_getInstanceMethod(class, originalSelector);
    Method categoryMethod = class_getInstanceMethod(class, newSelector);
    method_exchangeImplementations(originalMethod, categoryMethod);
}

+ (void)hijack
{
    [self hijackSelector:@selector(removeObserver:)
        withSelector:@selector(RNHijack_removeObserver:)];
}

+ (void)RNHijack_removeObserver:(id)notificationObserver
{
    NSLog(@"Removing observer: %@", notificationObserver);
    [self RNHijack_removeObserver:notificationObserver];
}

Then, somewhere early in my program, I call [NSNotificationCenter hijack]. Now, every removeObserver: message is logged, no matter who sends it, even inside Cocoa itself. To make sure that I catch everything, I often put this in main.m, before the call to ‘NSApplicationMain()’.

The line to pay particular notice to is the apparent infinite loop in RNHijack_removeObserver: that seems to call itself. Why does this work? Because method_exchangeImplementation() swaps the two implementations. The old removeObserver: now points to my implementation, but conversely RNHijack_removeObserver: points to the old implementation.

It is hard to imagine code that is more confusing and fragile than this, which is why this technique must be used with the utmost care. Personally I can’t imagine using this outside of debugging and profiling. But when you need it, it is an incredibly powerful tool.

Many of the objects I deal with include these, and there are a few special concerns:

• You can’t take a shared_ptr to an object during its constructor.
• You can’t easily store a shared_ptr directly in an ivar using the opaque object previously discussed (it relies on a raw pointer to a struct).

Consider the following object (slightly abbreviated; a WrapPtr is a shared_ptr<Wrap>):

class WrapListener {
public:
    virtual void onStringDidChange(WrapPtr wrap) = 0;
};

class Wrap : public enable_shared_from_this<Wrap> {
public:
    Wrap(string str) : m_string(str), m_listeners() {};
    string getString() { return m_string; };
    void setString(string str);
    void addListener(WrapListenerPtr listener) { m_listeners.insert(listener); };
    void removeListener(WrapListenerPtr listener) { m_listeners.erase(listener); };
private:
    string m_string;
    WrapListenerWeakSet m_listeners;
};

This is a very common pattern in the code I work with, but it has a problem for wrapping. If we make the opaque object the listener, there’s no easy way to call addListener() during the constructor. For example we might be tempted to do this:

struct RNWrapOpaque : public RN::WrapListener,
    public enable_shared_from_this<RNWrapOpaque> {
public:
    RNWrapOpaque(RNWrap *owner, string aStr) : 
    m_owner(owner), wrap(new RN::Wrap(aStr)) {
        wrap->addListener(shared_from_this());
    };

    ~RNWrapOpaque() {
        wrap->removeListener(shared_from_this());
    }

    void onStringDidChange(RN::WrapPtr cppWrap) {
        [m_owner.delegate wrapStringDidChange:m_owner];
    }       

    RN::WrapPtr wrap;
private:
    RNWrap *m_owner;
};

Unfortunately, this will crash. It’s not possible to call shared_from_this() during a constructor. This can often be solved by adding a Create() method to separate construction from initialization. That’s a good pattern, but doesn’t work here because there’s nowhere to store the shared_ptr. We have to store a raw pointer in the header.

The best solution I believe is to accept that you need a second object for the listener. This actually scales pretty well since the opaque struct may store several objects, and breaking up the different listeners can be better for readability. So that brings us to our example:

class MyWrapListener : public RN::WrapListener {
public:
    MyWrapListener(RNWrap *owner) : m_owner(owner) {};

    void onStringDidChange(RN::WrapPtr cppWrap) {
        [m_owner.delegate wrapStringDidChange:m_owner];
    }   

private:
    RNWrap *m_owner;    
};

struct RNWrapOpaque {
public:
    RNWrapOpaque(RNWrap *owner, string aStr) : 
    wrap(new RN::Wrap(aStr)),
    m_wrapListener(new MyWrapListener(owner)) {
        wrap->addListener(m_wrapListener);
    };

    ~RNWrapOpaque() {
        wrap->removeListener(m_wrapListener);
    }

    RN::WrapPtr wrap;
private:
    RN::WrapListenerPtr m_wrapListener;
};

@implementation RNWrap

- (id)initWithString:(NSString *)aString delegate:(id<RNWrapDelegate>)aDelegate {
    self = [super init];
    if (self != nil) {
        self.cpp = new RNWrapOpaque(self, [aString UTF8String]);
        self.delegate = aDelegate;
    }
    return self;
}

The rest is generally as in the previous article.

CppWrap.zip

First, to remind everyone of the problem: you have a C++ object that you want to consume in Objective-C. That’s easy in ObjC++, but if you make an ivar that references a C++ class, then the header file can only be included by ObjC++ classes. This quickly spreads .mm files throughout your project, creating all kinds of headaches. ObjC is a beautiful thing, and C++ is fine, but ObjC++ is a crazy land that should be carefully segregated from civilized code. So how do we do it?

We create a thin wrapper object to provide an ObjC face on a C++ object. The challenge is how to hide C++ classes from the header file. The answer is to put them in a struct that you forward declare so you don’t have to expose its contents. Structs are almost identical with C++ classes, but their forward declaration syntax is C-compatible (unlike class). Let’s look at how this is done.

For this example, we will consider a C++ class called RN::Wrap. It holds a simple string with set and get accessors.

class Wrap {
public:
    Wrap(string str) : m_string(str) {};
    string getString() { return m_string; };
    void setString(string str) { m_string = str; };
private:
    string m_string;
};

We wrap this into Objective-C++ using an opaque structure, RNWrapOpaque:

struct RNWrapOpaque;
@interface RNWrap : NSObject {
    struct RNWrapOpaque *_cpp;
}

Since we only include a raw pointer to RNWrapOpaque, we don’t have to declare anything else about it in the header file. If we tried to store the actual struct here (rather than a pointer), then that would defeat the purpose. This is the only raw pointer we will need.

Since structs are almost identical to classes in C++, we can use class features like constructors and destructors in the implementation (.mm file):

struct RNWrapOpaque {
public:
    RNWrapOpaque(string aStr) : wrap(aStr) {};
    RN::Wrap wrap;
};

Now initializing and using the opaque object is easy in ObjC++ code:

- (id)initWithString:(NSString *)aString {
    self = [super init];
    if (self != nil) {
        self.cpp = new RNWrapOpaque([aString UTF8String]);
    }
    return self;
}

- (void)dealloc {
    delete _cpp;
    _cpp = NULL;    
    [super dealloc];
}

- (void)setString:(NSString *)aString {
    self.cpp->wrap.setString([aString UTF8String]);
}

- (NSString *)string {
    return [NSString stringWithUTF8String:
        self.cpp->wrap.getString().c_str()];
}

A nice side effect of this usages is that C++ objects are easy to detect through the self.cpp prefix. Memory management is easy since there is only one raw C++ pointer.

Using the class requires no special work. It’s pure ObjC:

RNWrap *wrap = [[[RNWrap alloc] initWithString:@"my string"] autorelease];
NSLog(@"wrap = %@", [wrap string]);

In part two, we’ll discuss how to extend this approach to more complex problems such as smart pointers, listeners/delegates, and bindings.

SimpleCppWrap.zip

I’m currently studying speaking with Pimsleur Chinese Mandarin I Comprehensive. I’ve found it useful so far, and it seems a good way to learn pronunciation. Of course that can get you in trouble. It is somewhat problematic to learn very well how to say “I don’t speak well” (我说的不好). It gives the impression you are being modest, when in fact it is about the only thing you know how to say. I would have done better to study “I don’t speak Mandarin” (我不会说普通话).

To learn writing, I’ve been studying Learn to Write Chinese Characters by Johan Björkstén. Reviewers have been very complimentary of its focus on the aesthetics of beautiful and correct drawn characters rather than simply how to print them like a book would. I trust them for now that the focus on beauty is also good for learning.

I’m still on the lookout for a good dictionary. I use Google translate and wiktionary a lot, but I don’t like either. I’d like to find a good online resource that will take a character and give the pinyin and translation, as well as the reverse. A book form would be useful as well of course, though I’m still working on stroke counting and order, so that makes it hard to look things up.

printf("%s", 1);
NSLog(@"%s", 1);

And you compiled with -Wformat. You might expect both of these lines to kick out a warning:

Format '%s' expects type 'char *', but argument 2 has type 'int'

You’d be particularly misled when you went and looked at the definition of NSLog():

FOUNDATION_EXPORT void NSLog(NSString *format, ...) __attribute__((format(__NSString__, 1, 2)));

Why look there, doesn’t that look like it should provide format type checking? Oh how foolish. Neither gcc nor clang can actually handle that __NSString__ specifier in a robust way. So the first line above will give a useful warning, but the second one will silently compile and later crash. Exciting, I know. You have been warned.

-Wformat-nonliteral and -Wformat-security do catch dangerous calls like NSLog(foo), so __NSString__ isn’t a complete loss, but it’s a shame we can’t get type checking here.

There’s a good discussion of this at NSLog(…) improper format specifier affects other variables?

I’m a full-time Mac and iPhone developer today. I got here because I taught myself Mac development because I wanted a Pandora player that didn’t take over my browser. I read a book, started building my own, discovered PandoraBoy, joined that project and eventually took it over. Then a job opened up for a Mac developer, and because I’d just been doing what I love to do, I had the background to get that job. When iPhone became a big thing, we Mac developers had a huge head start on Cocoa, so we became iPhone developers. This is how careers can be built by just doing what you love and keeping an eye out for opportunities. I never had to quit my old job to pursue development; I just worked on Mac stuff in the evenings because it interested me. When a career showed up, I was ready.

If you love Java, then work on Eclipse or any of the other Java projects. If you love .NET, there’s plenty of opportunities to build things there. Don’t tell employers what you’d like to be paid for; show them the kind of work you do even when no one is paying you. I’ve interviewed a lot of people, and this is what I always look for.

To the question of whether iPhone can be a career, I know many people who have made it one and do quite well, and some who have made it one and barely scrape by. But in any case, it’s more a question of whether you have a passion for it. Follow your passion first and let the career follow. In software development we have the incredible flexibility of pursuing our passion without quitting our day jobs. We can work anywhere, any time, our materials are cheap once you have a computer, and we don’t have to set up a storefront to sell our goods. Embrace that.

Watch the job postings at Jobcoin. They come up quite often. Take on freelance work a piece at a time, or start a small commercial product of your own and see where it takes you. Use LinkedIn. Recruiters contact me there regularly, so there are definitely jobs out there. Write a blog. But most importantly, keep producing, whether someone is paying you or not. If producing is a chore, you’re probably chasing the wrong dream.

When I teach Cocoa, I always ask the class what their background is in. This generally tells me what they need to unlearn before they’re ready for Cocoa. Here are some of the things I’ve found that different groups need to unlearn.

For C++ developers:

• Naming. Correct naming is critical in Objective-C. The compiler will not save you. Learn the naming conventions and follow them.

• Dot notation. Dot notation is pleasant to type for experienced Cocoa developers, but extremely confusing to new developers. Dot notation does not mean “get or set the ivar of the object.” Dot notation means “pass the message -foo or -setFoo: to the object.” These two statements seem very similar, but are in fact radically different. Most importantly, foo and self.foo are not the same thing, though often they may appear to be the same thing. Assigning to the latter will generally retain the object, while the former will not.

• Following up on dot notation, accessors are not mandatory in ObjC, but should be. Always, always use them (except in the accessors themselves of course, and in -dealloc). Do not access your ivars directly. Not even if you see sample code doing it.

• The reason for all of the last three issues is memory management. If you will follow these last three rules, then your memory management will be easy and you will have very few problems. If you do not, and C++ folks often are very bad about this because C++ has such sloppy naming conventions, then you will have terrible memory management problems.

• Objective-C can use C++. I recommend strongly, however, that you keep your C++ and Objective-C separate, and have only a thin translation layer in Objective-C++. Learn to use NSArray rather than vector, etc.

• C++ developers often get confused about how Singletons are used in ObjC. If you understand the full, correct Singleton pattern, then you need to understand that ObjC generally doesn’t use it. It’s ok to have a static in ObjC that holds the “shared instance” and that you never free. OS X (phone and Mac) will recover the memory for you at program termination. It’s ok to have a “singleton” that can actually have multiple instances (NSNotificationCenter and many other objects allow this). There is seldom reason to really ensure that you are the one and only instance of the object (if you’re overloading -release, stop, even if you found the code to do it on Apple’s site). “Singletons” are generally just an instance that happens to be stored in a static and is returned when you asked for the “sharedController” or “sharedFoo” or whatever.

• Threading is somewhat rare in Cocoa. Most things are done on the Run Loop, which is cooperative multi-tasking. You get asked something, you respond as quick as you can, all on one thread.

For C developers:

• I push C developers to stay away from Core Foundation (things that start CF). Core Foundation is very useful, but it’s too easy to let it become a crutch to avoid actually learning Cocoa. It’s better to first learn Cocoa in ObjC, and then come back and use Core Foundation when you need to.

• Do not be afraid of long descriptive names. Get used to them. Love them.

• Embrace objects. Even the C-based Core Foundation is basically object oriented in C syntax.

• Don’t forget your C. A lot of Objective-C is done in straight-up C. It’s just C, really. C++ isn’t, but Objective-C really, really is just C.

• Objective-C is really C, but Cocoa isn’t. Cocoa is Smalltalk. And so you really need to study the Model-View-Controller paradigm and live it every day.

Java/C#:

• Java developers seem to have the hardest time with dot notation. I often just flat-out ban dot notation for former Java developers. Don’t use foo.bar, just use [foo bar] and [foo setBar:baz]. You will save yourself a lot of headaches. A Java background just seems to make it much harder to break the idea that dot notation is really a method call and nothing else.

• Even more than C++ developers, I have to teach Java developers that they aren’t going to spawn threads for things. Use the run loop, and do thing asynchronously with callbacks. As a beginner, you may never need to spawn a thread. I write a lot of complex code, and still only spawn maybe a couple of ObjC threads in a major program.

• C# developers (and Windows developers in general) have trouble with Interface Builder. When you create a button in Visual Studio, it writes a bunch of code for you. IB does not write code. IB serializes an object. A NIB is just an object archive. At run time, the NIB is read, and the objects are deserialized.

• Objective-C does not subclass a lot. It uses helper objects (delegation, datasources). If you have a special window that can’t be closed except in certain circumstances, you don’t subclass NSWindow (you almost never subclass NSWindow for anything). You assign a delegate to the NSWindow instance, and when it wants to close, it asks its delegate -windowShouldClose:.

• .NET has lots of objects that do similar things in different ways, and each time a new rev comes along, they give you a new set of objects that do those same things in new ways. .NET objects tend to be really smart with lots of little fiddle knobs to configure them. Cocoa objects are dumb, and that’s why I love them so much. A table view in Cocoa doesn’t know anything about querying SQL servers. A table view knows how to draw a table. It asks its datasource for what that data should be, and it asks every time it gets ready to draw a cell. It asks its delegate how tall each rows should be and whether a given row may be selected, just at the moment it needs the information. This is backwards of how .NET generally does things.

And that leads to my biggest point for developers coming from anywhere that isn’t Smalltalk:

• It isn’t about you. It isn’t about your code. And it isn’t about your code doing this or that. It’s first about the user and responding to the user. It’s second about your code responding to the framework. You don’t usually tell the framework what to do. It asks you for things when it needs something. You sit and wait for it to talk to you. You’re not in charge. You don’t control the runloop; it controls you. You register to be told when things happen, and you indicate that you’re the object who knows something about something (data for a table for instance). And then you let go, and let Cocoa do the rest. It’s a very different world. I like it very much.