On Mar 4, 2016, at 5:24 PM, Jonathan Mitchell <li...@mugginsoft.com> wrote:
> Hi Alex > > Not sure if this will help at all as I am not 100% sure what you are doing. > In my case, using Mono, I needed to track events being raised in the Mono C > runtime back into Obj-C space. > You need some method of defining a call back function in the target C Api - > without that thinks would look rather bleak. Yes, this is exactly what I am a looking at figuring out. > Basically the C Mono runtime is configured to a call static C function in an > Obj C .m file in response to a C# managed event firing. > The static then calls a static method on an Obj-C class. > This Obj-C static uses collections to track registered events and invokes > performSelector: on a registered Obj-C target. > See here: > https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/Framework/XCode/Representations/DBManagedEvent.m Bingo. That is what I need to read. > One of the arguments based in as part of the event callback is a pointer that > is used as a a key to retrieve the target NSObject. > This is complicated by the fact that the incoming pointer represents a > moveable memory location so there is some extra indirection too. > https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/Framework/XCode/Representations/DBPrimaryInstanceCache.m > > This can get a bit complex but its all doable. > > Jonathan Wonderful. I believe you’ve outlined the issues that I will be facing and need to be aware of. I already have some samples that I didn’t know were doing part of what you’ve outlined, but I had no idea that’s how it was being done due to my ignorance of C matters. Well, now I know what I’ll be doing this weekend. Thanks, Jonathan. You and Doug are certainly pointing me in the direction I need to be header. Alex Zavatone >> On 4 Mar 2016, at 21:14, Alex Zavatone <z...@mac.com> wrote: >> >> Great! It certainly does… but here's where my brain breaks. >> >> The call is originating from the C lib and within the C function. I am not >> calling the C function from Objective-C. >> >> I'm looking at somehow passing this as a string (UTF-8, yep) back to an OC >> class instance, so this implies either a callback or some reference to the >> OC instance that that cares about the response and a means to get that >> message to it. >> >> If this is as simple as setting up a callback or a pointer reference, from >> the c class to the OC instance? Is it sane programming for the C class to >> have more than one callback to different OC object instances? >> >> I was thinking one for data and one for method calls for organizational >> purposes. >> >> Or should there be one layer that serves as a clearly defined API to create >> a walled garden between the OC world and the C interface to the compiled C >> lib? >> >> I'm working with PJSIP and PJ's docs clearly state, "we are going to crater >> unless you do everything SIP related on the main thread." The code that I >> am rewriting replacing has nasty try/catch clauses and forces many >> operations to the main thread just in case they call PJSIP operations - >> which clearly makes for a sucky user experience and really clunky >> application architecture. >> >> I'm looking to avoid that nastiness by starting from ground zero so that we >> can wrap a solidly conceived architecture around a neatly walled off >> interface layer to PJSIP. >> >> >> Would it make sense to send a notification from the C method to an >> Objective-C object to get the value from the C class? Then I'd need to >> worry about storing it, that seems clunky and too involved just to return a >> string. >> >> Thank you, sir. Loads for me to learn here. >> >> Alex Zavatone >> >> >> >> On Mar 4, 2016, at 3:48 PM, Doug Hill wrote: >> >>> Alex, >>> >>> I’ve worked on a few wrapper libraries, so I have some experience with this. >>> >>> In your Obj-C wrapper, you would need to create the NSString yourself. So, >>> if you have a C function: >>> >>> char* MyCFunc(void); >>> >>> The Objective-C wrapper method would do something like: >>> >>> - (void) myObjcMethod >>> { >>> char* cStr = MyCFunc(); >>> NSString* objcStr = [[NSString alloc] initWithUTF8String:cStr]; >>> >>> return objCStr; >>> } >>> >>> Depending on the C function implementation, you might have to deal with >>> releasing the C string in your wrapper. Also, I assume UTF-8 encoding, >>> which may or may not be true. >>> >>> Hopefully this helps you. >>> >>> Doug Hill >>> >>> >>>> On Mar 4, 2016, at 12:07 PM, Alex Zavatone <z...@mac.com> wrote: >>>> >>>> I'm in the middle of some fun where there is a wrapper class to a lib >>>> that's written in C and the c function has a char string that I'd like to >>>> return back to or somehow pass on to an Cbjective-C class. >>>> >>>> I'm sure there is an established practice for performing this type of >>>> task, but while I have the opportunity to do this, I'd like to start be >>>> learning the right way to handle this operation. >>>> >>>> I've seen really poor use of a catch all delegate for this approach, but >>>> am pretty unsure on viable and safe methods to handle this. >>>> >>>> Any tips to how to handle this? >>>> >>>> Thanks in advance, >>>> >>>> Alex Zavatone >>> >>> >> >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/lists%40mugginsoft.com >> >> This email sent to li...@mugginsoft.com > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
