I can't solve next problem: I have 2 applications which talk to each other using Distributed Objects. Suppose application A call - (void)updateState:(State *)state method from application B.
#interface State : NSObject <NSCopying, NSCoding>...
When updateState: method called in B app I have NSDistantObject representing sended object instead of State object. In Friday Q&A I found that if object conforms to NSCoding protocol the object should be 'sended' instead of proxy, but, I still receive a proxy. I don't find any info about it in Apple Documentation. Maybe someone does know how can I send object instead of proxy and how Distributed Objects system decide when serialize and send an object and when a proxy?
I found it! Also, you should implement - (id)replacementObjectForPortCoder:(NSPortCoder *)coder in object, which you want to pass through. More about this method you can read in Apple documentation.
Mystical isBycopy and isByref of NSPortCoder, which Apple refs to documentation, but in last is no info, determined by bycopy and byref method parameters keywords. More about this keywords you can read here.
Related
I really hope someone can answer this one. I think I am definitely not the only one confused about this and I wasn't able to find anything that clearly explains this concept.
My understanding of the delegation pattern comes from studying the Cocoa framework. To me, the Cocoa implementation is very clear. But I am having a very hard time understanding it in Ruby (standard library's Delegator, SimpleDelegator vs. ActiveSupport's Delegate). It makes little sense to me. Mostly because one is type safe the other is duck type. You can see my point already, but allow me to expand... Here is my summary of how to use the delegate pattern in Cocoa:
Our "ingredients" are: 2 classes, A and B and a protocol, which is Cocoa for a pre-defined set of methods to use for delegation.
The implementation of the pattern is basically as follows:
A defines the set of methods to delegate to B.
B's delegate is set to be A
=> B can now call delegated methods like so: #delegate.send(a_delegated_method)
What I am not tying together is the fact that Ruby uses duck typing, so you can send any method call to any object, right? So using the pattern I just explained, as long as the 2 objects are in the same domain you can say while in A #b.send(:a_delegated_method) and vice versa while in B #a.send(:another_delegated_method).
Could it be that the point with delegates in Ruby is where the delegated method is defined? Meaning that we send from within class A to property #b (#b(:delegated_method)) a :delegated_method defined within A itself?
Hope this isn't too confusing. I myself am confused about why delegates even exist in a duck typing language and what the differences are between Delegator, SimpleDelegator and ActiveSupport's Delegate.
It isn't clear to me that you have understood how delegation works in Cocoa. It is true that the common variety of the delegation pattern in Cocoa involves a protocol, but that's just a way of quieting the compiler.
So let's talk first about quieting the compiler. You can't send the woohoo message to an object in Objective-C unless one of two things is true:
The compiler has reason to believe that this object might respond to the woohoo message.
The compiler is made to suspend judgment.
Nowadays, the first approach is usually used - that's what a protocol is for. But this was not always the case. It used to be that delegation depended mostly on informal protocols. And there still are informal protocols in Cocoa. The idea is that either the method is injected into NSObject by a category, or else you are careful to type the object as id so that it can be sent any message at all.
Now let's talk about dynamism. The reason informal protocols are no longer used is that a feature was introduced allowing protocols to declare optional members. But dynamism is still needed! We may satisfy the compiler, one way or another, but at runtime we have to make sure that it is safe to send a certain message to a certain object. Your app delegate may adopt UIApplicationDelegate, but Cocoa is not going to send it the applicationDidBecomeActive: message unless your app delegate class implements applicationDidBecomeActive: - if it did, you'd crash, and that wouldn't be very nice.
Moreover, if you can just get past the compiler, you can perform delegation in Objective-C even more dynamically than that, as explained here:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtForwarding.html
The idea is that we go right ahead at runtime and send the object the message anyway! If a message arrives that Object A can't handle, it can see if Object B handles it. If it does, it passes the message along to Object B. So we might not crash after all!! I use that approach in one of my apps:
- (id)forwardingTargetForSelector:(SEL)aSelector {
if ([self.originalDataSource respondsToSelector: aSelector])
return self.originalDataSource;
return [super forwardingTargetForSelector:aSelector];
}
In that code, I'm saying that if a message arrives and I can't handle it, I should try to get it sent on to another object, called self.originalDataSource.
If you think about it, that is almost identical to Ruby delegation. I have a helper object, and messages that I can't handle are passed on to it.
Another common use of this pattern is when wrapping a Cocoa collection. You can't subclass, say, NSArray, because it's a class cluster, so the proper approach is to wrap it. You then just forward everything to the NSArray, and presto, you are duck-typed as an NSArray! You look like an NSArray as far as your methods are concerned. Then you introduce some difference in behavior, and now you are duck-typed as a customized NSArray.
I'm sure this must be a stupid question, but I've scoured the interwebbings and can't find the answer. Plenty of people talk about using the Generation Gap pattern, in which you have an NSManagedObject subclass that is generated from your model, and then subclass that to add transient properties and behaviours. The benefit of this is that if you change your persisted model, you can just generate your base files again without any danger of overwriting your own code.
I have a base CardMO object derived from NSManagedObject. I then subclass this to make my own Card object.
My question is, how do I create a Card object that is managed?
I tried:
Card* card = [NSEntityDescription insertNewObjectForEntityForName:#"CardMO" inManagedObjectContext:moc];
But this object isn't really a Card, and of course there's an exception when I go on to call a Card method on this object.
I've tried creating a Card with alloc / init (where init just calls [super init]), and then adding it to the managedObjectContext like this:
[moc insertObject:(CardMO*)card];
This gives me the cryptic error "Failed to call designated initializer on NSManagedObject class 'Card'"
I've tried modifying this by calling [NSEntityDescription insertNewObjectForEntityForName:#"CardMO" inManagedObjectContext:[AIStoreManager sharedAIStoreManager].managedObjectContext] instead of [super init]. In this case the object I get back is again a CardMO, and I can't call Card methods on it.
What should I be doing?
And (for bonus points :-) - after I've passed this hurdle, I need to create my other Card objects from XML, and then turn them into NSManagedObjects. I'm using code based on Apple's XMLReaderSAX - I hand this code a chunk of XML, and it gives me back an array of many Card objects. Can I later add these objects to my managed object context, or do I have to get into XMLReaderSAX and change how it creates those objects?
I'm writing an iPhone app on 3.0, but I assume this is the same for Core Data for 10.5.
Sussed it!
In the data model, the class name for the entity has to be that of the most derived class - Card in my case. The trouble then is that you have to remember to change the name to CardMO before generating any new files.
This must be why people use mogenerator.
Why not use NSCoding? Then you could support XML or JSON or any other means of describing the object outside your application.
I'm using Cocoa bindings to manage a table of objects. I understand how bindings work but I've run into a slight problem. Managing the table of objects would be fine and dandy, except that those objects have to manage actual bluetooth hardware. I'm working off of a framework that provides a class representing a connection to this hardware, and have made another "manager" class the makes it key-value compliant. In other words, this manager class has to be able to connect and modify its "connect" status in its properties dictionary, be the delegate of this hardware and modify properties, and update the hardware with changes made.
However, whenever I set new values within the object itself, like in a "connect" method that would change the "connect" key's value to 2 (looking), (i.e. propertiesDict = newDict), the change is not seeming to be picked up by observers that it is bound to. I've looked at the observeValueForKeyPath:ofObject:change:context: in the NSKeyValueObservingProtocol. However, I don't know what to do with the context argument.
I hope that makes sense... but if anyone has any ideas I'd love to hear them.
Your question isn't totally clear, but if I'm understanding it correctly the issue might be because you need to send manual KVO notifications before and after you change a value in the embedded object. For instance, [self willChangeValueForKey:#"connected"]; and [self didChangeValueForKey:#"connected"];.
There are three ways to update a property/attribute in a KVO compatible way:
Using the property setter (specified in #property declaration or generated by #synthesize)
Calling -willChangeValueForKey: and -didChangeValueForKey: before and after you change the property value in any way.
Calling -setValueForKey:
I would like to code a proxy that forwards method invocations to another object over TCP without NSConnection and NSDistanceObject stuff. What I want is my own protocol.
The problem is that subclassing NSProxy and overriding forwardInvocation: is not sufficient. I have also to override methodSignatureForSelector
Here is my question:
– (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector
{
return ???
}
#Brian, This may be ok, but setProtocolForProxy: is just for optimization. cocoafan could mandate it for his solution, but it wouldn't be a drop-in replacement. You're supposed to be able to get signatures automatically. To do that, the network protocol needs a way to request the signature.
I believe the solution here is to include in the network protocol a "request method signature" method, and have it run methodSignatureForSelector: on the distant object and encode and return the result. That's what NSDistantObject does.
Providing setProtocolForProxy: is an important optimization if you're going to chatter a lot, but it does restrict you to objects that you have a protocol for, and prior to 10.5 that introduces some annoying limitations (all methods are required). Even on 10.5, it may introduce some problematic limitations if it's the only way to get method signatures.
#cocoafan, I think you're probably right to create this from scratch on top of NSProxy, but do take a look at NSConnection and see if you can sub-class it to manage the network connection the way you want. If you can find a way to do that (though I don't see an easy way right off), you'll probably get a lot of stuff for free from NSDistantObject.
The way NSDistantObject handles this is by its setProtocolForProxy: method, which specifies a protocol containing the list of methods that the object on the other end of the connection handles. It can then use the information for these methods to provide appropriate NSMethodSignature objects when doing forwarding.
It looks like the most straightforward to do that is via the protocol_getMethodDescription() function, declared in <objc/runtime.h>. This returns an objc_method_description struct which contains a types field. I believe you should be able to pass that value into +[NSMethodSignature signatureWithObjCTypes:] to get a method signature object that matches what's declared in the protocol.
I found a smart solution to generate NSInvocation objects.
I'm writing a Cocoa API for a project and the API takes a delegate. The protocol that I came up with declares all the methods as optional, but why would I do that instead of just documenting the delegate methods in a header file and taking a plain id as a parameter?
For the benefit of your users. If the object takes delegates conforming to some protocol and they pass something else in, the compiler can tell them. That isn't possible if you take an id and use a category as the delegate method interface.
Because having "all of these methods" optional isn't quite the same as permitting "anything you care to send".
It also produces code that is more usable in the IDE. For example if I'm looking at
#interface MyController : NSObject <FooBarDelegate> {
}
#end
I can command+double click in Xcode to jump to the definition of FooBarDelegate. With a category there's no formal declaration of intent to be a delegate.
Also, #required can be a problem for future plans with regard to backward binary compatibility and a new preferred method signature.