Re: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?
Re: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?
- Subject: Re: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?
- From: Alex Zavatone <email@hidden>
- Date: Fri, 04 Mar 2016 18:42:08 -0500
On Mar 4, 2016, at 5:24 PM, Jonathan Mitchell <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden