I would like to trace out all messages sent by the Objective-C runtime to a particular class, say UITableView (or a particular instance) so I can better understand the inner workings of some classes. Is there a way to do this?
Another use case is to trace out all delegate methods that are being called (say UITableViewDelegate methods) without having to declare them and put a trace method in each of them.
This may be a little heavy-handed, but try setting the NSObjCMessageLoggingEnabled environment variable to YES. That will show all the messages sent to every object, but you can easily filter it down to the messages sent to a particular class.
Some good tips here: http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/
Disclaimer: I'm not sure if the environment variable works for iPhone.
Related
I was looking for this on google and I found some articles on it They say it is used for HigherOrderMessaging and I tried to read the code to but everything was over my head can any body give simple example of it how we can use them? They were saying its used for passing returned object from method to another object. And another question when I develop apps never came situation where I need to use something like this.
In Objective-C, a trampoline is an object returned by a method that exposes some kind of message interface. When messages are received, it bounces the message on to another object.
Example One:
Return a proxy of a service client. When methods are invoked on the proxy, it first checks if the user has permission to proceed.
Example Two:
Make all the objects in an array do something:
[[windowsArray do] setHidesOnDeactivate:YES];
You have a class that has to send a message to its parent. This class is not used by any other member of your application. You send the message as a NSNotification or you create a delegate protocol on that class and implement the delegate method in the parent, so you can send the message?
What is the best approach and why? There's any advantage of one method over the other?
Thanks
Notifications is useful for when you have multiple observers or objects that are interested in the notification. They're also useful for Key Value Observing.
Delegates are very useful for sending a message (which conforms to the protocol that you declare) from one object to another object designated as the delegate target.
While both approaches could be used to satisfy the described messaging requirement, a delegate protocol is the better suited choice in this case.
The benefit of notification as pattern is that many objects may respond to a notification which has been posted. An object wishing to observe notifications need only register to receive them. An advantage to this is that your code is very loosely coupled (generally a desirable value in oop). The drawback to the loose coupling in this case is the fact that you have potentially related behavior occurring across different classes and essentially all over your code base.
A delegation pattern is more tightly coupled, and your delegate object must conform to the protocol of the object it will receive messages from. Because of this, it is relatively easy to observe the nature of the interaction (or intended interaction) between the notifying object and the notified object - it's easier to grasp, simply by looking at the code, object messaging between two "related" objects. In a case where you have a child essentially announcing some behavior (which is directly related to the behavior of the parent, presumably), I think delegation is a superior approach.
I added an index search to a core data backed UITableView. the search works fine, however after navigating back to the tableView I get this error:
-[NSSQLRow controllerDidChangeContent:]: unrecognized selector sent to instance 0x815edf0
I can post more code if this is too little information to go on.
thanks for any help
In Xcode (3), enable:
Run > Stop on Objective-C Exceptions
run your program in Debug.
Ultimately what is happening is an (objc) object is requested to perform a message which it does not respond to (i.e. is not implemented).
Typically, this happens as a programmer's mistake (at least, for me), such as an argument passed as another type, which slips through a cast, id, or objc_object container (e.g. any collection class - NSArray, NSSet, NSDictionary).
Sometimes this happens if you forget to implement the instance method.
Sometimes this happens if you are testing against an earlier release of the software, which did not implement the instance method (i.e. it was added in a following release).
Can anybody explain the importance of NSNotificationCenter?
Where to use them?
What is the difference between NSNotificationCenter vs. AppDelegate?
Apple has provided an Observer Pattern in the Cocoa library called the NSNotificationCenter.
The basic idea is that a listener registers with a broadcaster using some predefined protocol. At some later point, the broadcaster is told to notify all of its listeners, where it calls some function on each of its listeners and passes certain arguments along. This allows for asynchronous message passing between two different objects that don't have to know about one-another, they just have to know about the broadcaster.
You can find more details about it here: http://numbergrinder.com/node/32
The Application Delegate is an object which receives notifications when the UIApplication object reaches certain states. In many respects, it is a specialized one-to-one Observer pattern.
You can read more about it here: What is the AppDelegate for and how do I know when to use it?
If you come from an Actionscript background then NSNotification is like adding listeners to objects I guess.
NSNotification is like notifying the other class about the changes that will happen if some action takes place in another class.
Not even sure if the title is correct, however, what I'm trying to do is use the standard NSURLConnection class to handle responses from calling my webservice. I am using the POST method to update a database and the GET method to retrieve rows from the database. The problem I have is that these 2 actions may occur simultaneously so that the methods to handle the request may step on each other. In other words in my "connection didReceiveData" method I have 2 paths through the code depending on whether I'm handling a response from a GET or POST request.
I keep track on which request in being processed by an instance variable called requestType. The problem is that since the requests are being executed simultaneously the instance variable is being changed from GET to POST before the GET completes (or vice-versa). My question is how do I maintain 2 separate requests in this scenario? Do I synchronize the requests? Is there a way for threads to work here? Do I create 2 separate objects for each of the requests and have the logic in "didRecieveData" query for which object is being processed? Any help would be much appreciated!!
Dealt with a similar issue in one of our apps. The solution involved creating a class that represents a webservice call, responsible for calling its own url, loading its own data, etc. The call class had a delegate that would handle parsing the responses (in our case, a web service controller). Wound up getting rather complicated, but prevented the issue of NSURLConnections stepping on each other.
Seems like you've created a messy problem by having a class that tries to do too many things. I would suggest taking one of the following three approaches:
1) Write two classes, one for updates and one for retrievals. Each class creates it's own private NSURLConnection object and acts as the delegate for the async notifications received from the NSURLConnection. The classes could possible share some utility parsing code or extend a base object that has that parsing code in it. But the key being that the code calling these classes would instantiate one of them, make the call, and then release it. This will keep your code cleaner and will insure that the event notifications don't get intermingled.
2) Create a single class that, depending on initialization, does either a post or a get with it's own private instance of NSURLConnection. When a call needs to be made, instantiate the class, get the results, and then release the class.
3) Write your connection handling classes so they use the synchronous NSURLConnection method and call that call that class in a background thread.
Either way, clean code and clear object orientation will prevent messy scenarios like the one you're describing.
Create separate objects that handle the calls. If you want to issue multiple requests at once I would strongly recommend looking at NSOperationQueue, and making these objects subclasses of NSOperation... much nicer way to deal with multiple background requests.
A good example is here:
http://www.cimgf.com/2008/02/16/cocoa-tutorial-nsoperation-and-nsoperationqueue/
The idea there is that you use the non-asyncronous web calls, in operations that are run on separate threads. You can still use asynch calls in NSOperation as well, but doing so is a little trickier and for simple calls you probably do not need to.