Re: Newbie question: Object as input arguments
Re: Newbie question: Object as input arguments
- Subject: Re: Newbie question: Object as input arguments
- From: Ken Thomases <email@hidden>
- Date: Wed, 26 Nov 2008 18:57:03 -0600
On Nov 25, 2008, at 2:14 AM, Jose A. Guerrero-Colón wrote:
Imagine that we have a cocoa application, "App_A" which create an
object with information introduced by the user (the object is rather
ellaborated and complex). At the very last point of this
application, I would like to pass that object as input to another
application, say "App_B", and then finish the execution ("App_A").
What are the tools provided by cocoa / objective-C to cary this out?
None, at least not in the way that you envision.
An object or object graph lives in a process's address space. One
process doesn't usually have access to the address space of another.
(You can use shared memory to overcome that, but you're going to
create an awful mess if you try to make Cocoa objects play nicely with
shared memory.)
I have been exploring and found NSKeyedArchive which may be useful,
but I found it odd to force to the class of the objects (and all the
classes that it uses) to conform NSCoding protocol. Is there a
better option to do this?
You do have to make all the objects in the graph support coding. The
way around the address space limitation is to archive the object
graph, pass it as plain data to another process, and then reconstitute
a copy of the object graph in that second process.
You have a couple of options for passing the data:
* Store it in a file
* Store it in the preferences (a.k.a. user defaults) database,
although this is something of an abuse of the purpose of this database
* Store it in a pasteboard, perhaps
* Use Distributed Object in the brief period of time when both
processes are running simultaneously. Be sure to pass the objects by
copy.
I wonder if that could be done in a "fork -exec" fashion as well,
maybe using NSThreads? (Note that App_A will end just after calling
App_B)
NSThreads are no help at all. They are completely internal to their
owning process.
Fork (without exec) is the way something like this would be done for a
pure-C program, but it doesn't work for anything which uses the
frameworks. See the note "CoreFoundation and fork()" at this page <http://developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html
>.
A call to an exec*() routine would wipe the memory of the new process,
thus obliterating your object graph.
Lastly, I have to say this is a pretty weird request. Why do you want
to chain applications like this? If App_A is ending and passing work
off to App_B, why not just have App_A "become" App_B by subsuming its
responsibilities and perhaps changing its mode of operation?
Regards,
Ken
_______________________________________________
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