selector

So, I've been messing around with the objc-runtime again (surprise surprise), and I found an interesting block of code here : const char *sel_getName(SEL sel) { #if SUPPORT_IGNORED_SELECTOR_CONSTANT if ((uintptr_t)sel == kIgnore) return "<ignored selector>"; #endif return sel ? (const char *)sel : "<null selector>"; } So, what this tells me is that a SEL is equivalent to a C-string, in every mannerism. Doing a hex dump of the first 16 bytes of SEL that contains @selector(addObject:) gives the following: 61 64 64 4F 62 6A 65 63 74 3A 00 00 00 00 00 00 Which is equal to the C-string addObject: .

When the user presses a ListView item (android:state_pressed="true") it flashes a shade of yellow (or you can press and hold). What drawable is this? I've created my own selector because I want my own ListView item color , but I lose the pressed color. There's an Android doc about skinning buttons that references #ffff0000, but this produces red. Does anyone know what it is and how to reference it? Jonas The default system resources can be found in <android-sdk>/platforms/android-<version>/data/res . In particular, the list selector is defined in drawable/list_selector_background.xml :

Question We're developing a custom EventEmitter inspired message system in Objective-C. For listeners to provide callbacks, should we require blocks or selectors and why? Which would you rather use, as a developer consuming a third party library? Which seems most in line with Apple's trajectory, guidelines and practices? Background We're developing a brand new iOS SDK in Objective-C which other third parties will use to embed functionality into their app. A big part of our SDK will require the communication of events to listeners. There are five patterns I know of for doing callbacks in