Skip to content

Conversation

tomaz
Copy link

@tomaz tomaz commented Nov 29, 2011

Hey! I've adopted XPCKit to my app and it's been really smooth sailing so far (much smoother then using XPC API directly, not to mention clearer code etc). Gladly I've code across your lib as I was about to write my own (not nearly as sophisticated, just to cover my needs). Anyway, I added two things which I use in my app:

  • ARC support: works for both non-arc and arc builds, although it makes the code a bit ugly due to #if/#else statements. If you later port it fully to ARC, you can remove all the conditionals (probably makes sense as XPC itself is Lion only, so probably folks will also adopt ARC).
  • Error reporting support: there's additional block handler in XPCConnection that's invoked when an error is detected. Also updated TestApp to demonstrate how it can be used.

If you think this would be useful for other users, feel free to merge into main repo, otherwise just close the pull request :)

Thanks for the lib! Tom

Errors are handled in similar way as messages - through block handler. Original xpc_object_t object is passed through, so user can check what kind of error it is (i.e. XPC_ERROR_CONNECTION_INTERRUPTED etc). Second parameter is user friendly description retrieved from the error object via xpc_dictionary_get_string() function and lastly the connection itself.
@avaidyam
Copy link

Instead of the if/else preprocessor directives, consider macros like this:

#if  __has_feature(objc_arc)
#define OBJECT_AUTORELEASE(object) (object)
#elseif
#define OBJECT_AUTORELEASE(object) [(object) autorelease]
#endif

... and so on. This way, one macro controls everything and can be modified accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants