I am about to complete the project and I want to add logging in it. I know there are some good loggers are available in market(CocoaLumberjack). But for that I need to add log statement into each and every method. As project is about to complete there are lots of methods. So, is there any way or work around ? Without adding log statement into all methods If I will add at any central place and it will work for all.
I am not sure if there is such Objective-C runtime function that is called before every method.
This method will be helpful in all cases like I am or any new dev is writing new method then he don’t need to remember to add log statement.
Edit:
This is just for a debugging purpose. And I will add a way to control the logs like turn off and print detail of certain level.
Don't do this. Seriously. Users don't appreciate their log files filling up because of chatty software, and you'll also annoy every other developer by obscuring messages that are actually important.
You should only use NSLog() this way as an absolute last resort during debugging. Even then, there are better approaches (e.g. you could use dtrace; if you get it to dump all objc_msgSend() invocations, you'll see almost all of your method calls, aside from those that pass through objc_msgSendStret() and the floating point ones if applicable to your platform).
If you really must make a chatty application, create your own log file, write your own logging function (ideally using asl), and it’s a good idea even then to have a set of flags that can be controlled e.g. from user defaults to enable different kinds of debug output.
How about a category of NSObject with this override?
-(BOOL)respondsToSelector:(SEL)aSelector {
printf("Excessive Log: %s\n", [NSStringFromSelector(aSelector) UTF8String]);
return [super respondsToSelector:(aSelector)];
}
Related
Once in a game I was playing, a smart person wrote a cheat that allows you to disconnect all players from the server. I became interested in how it is possible to create protection against this. The situation was aggravated by the fact that the person who created the cheat distributed it to other players and disconnecting from the server became a regular event.
I got the source code of this cheat, I will show a fragment with a "connection switch":
I figured out how the cheat works. In the LLDB debugger, I found the Disconnect() function, it is called just when the "cheater" uses the cheat. In the disassembler, I decided to just remove Disconnect (), of course this is stupid, because I violated the logic of the game because of which I could not play. As a result of something, this function was called for me, I need to find out what code was executed before the breakpoint with Disconnect ()
Well its hard to tell, but my suggestion is you add some Debug.Log prints in certain scripts you think could be called before the disconnection happens, I know this sounds like a tedious work but you probably have some scripts you think could be called before. Else I would search for some keyword like "kickall" and be sure to set "all files in project" option so that it shows all possible candidates. I hope this serves you
I've spent quite a bit more time than necessary to figure this out, and came up with zilch! This may not be the most kosher way to do what I need, but in the legacy version, I found it easy enough to use in practice. Basically, I'd have a specially named logger, and I want it to be enabled (i.e. logging diagnostic) only if it's explicitly enabled (i.e. specified in the XML configuration file).
The hierarchical fashion the logger configuration works would cancel this out if ROOT logger is set at a lower level than my log lines. It would log this particular logger's lines, even if I don't want it to (yes, I know this is not the expected usage).
In legacy log4j, there were 2 ways to get the "level": getLevel and getEffectiveLevel. Effective traversed up the hierarchy, and the regular one returned the value at my particular logger. Using this, I could check the Level, and if it's null (i.e. not explicitly specified in my configuration), I'd programatically set the level to be OFF, and disable it.
There doesn't seem to be a way to access that piece of information in the straightforward part of the API. Looking through the object model in debugger, I've found the following map that could be checked if it contains the name of my logger or not, but it seems a bit convoluted:
LoggerContext.getContext(false).getConfiguration().getLoggers()
Is there another/simpler way to achieve this? Or should I just take my square peg, and move away from the round hole?! :)
I wish to insert hooks whenever a method is called in my iOS app. So lets say there is a selector X, I wish to log "Method X starting" before the method executes, and then log "Method X ended" after the execution. I am aware of an approach where I can swizzle the implementation of sel X with the one which has the hook before and after the call to "itself", so that I can be notified when the method has executed. But, this will only work if i know the method in advance. I wish to insert hooks for all the methods that execute, even if I do not have access to the source code of the class executing it (for example a third party closed library executing an internal method). The intent behind this is logging the time taken for execution of each and every method in my app. I am aware that I cannot override objc message send method call to intercept methods. Does NSObject have some functions that are called before and after a method gets executed?
It sounds like what you actually want is to run your app in Instruments' "Time Profiler" tool. This will log all the method invocations for you and show you which ones are taking the greatest amount of time in your app.
To answer your original question, you don't actually have to know the methods ahead of time; you can just use class_copyMethodList() to get a list of methods and then iterate over them. I would discourage actually going this route, though, as Instruments is a better tool for this sort of thing.
Believe me you don't want this. As you think on a higher level that calling a function and logging the start and end to it is good, it won't do you any good for the following reasons:
1- Function will call many many lower level fuctions: addSubview itself will call many functions alone, and the function it calls will call many fuctions inside as well. You think you are about to call 1 function, but this log will be triggered +20 times in this case.
2- logging all functions is actually extra code in your case. Extra code means extra effort to the app. What you will do is basically impact the performance and battery usage dramatically.
3- Apple makes sure its core functions are seriously optimized and spends a lot of time on them to ensure they are at their best (in some xCode releases they are updated as well)
My advice is to log your functions, if you're trying to achieve a specific goal. but generally logging objective c is not recommended.
PS: In case you are trying to check the time for every function, there are tools that will show you which functions are taking what times.
I am using gocraft/web in a project and am trying to debug some high memory usage. gocraft/web uses reflection to call handlers. I've set up the net/http/pprof profiler which works very well, but the largest block of memory, and the one that I am iterested in, only shows reflect.Value.call as the function. That's not very helpful.
How can I get around the fact that gocraft/web is using reflection and dig deeper into the memory profile?
Here's an example of the profile output I am seeing:
Thanks to #thwd for filing http://golang.org/issue/11786 about this. This is a display issue in pprof. All the data is there, just being hidden. You can get the data you need by invoking pprof with the -runtime flag. It will also show data you don't need, but it should serve as a decent workaround until Go 1.6 is out.
The short answer is that you can't directly. reflect.Value.call calls reflect.call which forwards to runtime.reflectcall which is an assembly routine implemented in the runtime, for example for amd64, here. This circumvents what the profiler can see.
Your best bet is to invoke your handlers without reflection and test them like that individually.
Also, enabling the profiler to follow reflective calls would arguably be an acceptable change to propose for the next Go iteration. You should follow the change proposal process for this.
Edit: issue created.
I worked my way through the Prism guidance and think I got a grasp of most of their communication vehicles.
Commanding is very straightforward, so it is clear that the DelegateCommand will be used just to connect the View with its Model.
It is somewhat less clear, when it comes to cross Module Communication, specifically when to use EventAggregation over Composite Commands.
The practical effect is the same e.g.
You publish an event -> all subscribers receive notice and execute code in response
You execute a composite command -> all registered commands get executed and with it their attached code
Both work along the lines of "fire and forget", that is they don't care about any responses from their subscribers after firing the event/executing the commands.
I have trouble seeing a practical difference in usage although I understand that the implementation of both (under the hood) is very different.
So should we think of what it actually means - Event? Is that when something happens (an event occurs)? Something the user did not directly request like a "web request completed"?
And Command? Does that mean a user clicked something and thus issued a command to our application, requesting a service directly?
Is that it? Or are there other ways to determine when to use one of these communication vehicles over the other. The guidance, although one of the best documentations I read, gives no specific explanation.
So I hope people involved in/using Prism can help in shedding some light on this.
There are two primary differences between these two.
CanExecute for Commands. A Command
can say whether or not it is valid
for execution by calling
Command.RaiseCanExecuteChanged() and
having its CanExecute delegate
return false. If you consider the
case of a "Save All"
CompositeCommand compositing several
"Save" commands, but one of the
commands saying that it can't
execute, the Save All button will
automatically disable (nice!).
EventAggregator is a Messaging
pattern and Commands are a
Commanding pattern. Although
CompositeCommands are not explicitly
a UI pattern, it is implicitly so
(generally they are hooked up to an
input action, like a Button click).
EventAggregator is not this way -
any part of the application
effectively raise an EventAggregator
event: background processes,
ViewModels, etc. It is a
brokered avenue for messaging
across your application with support
for things like filtering,
background thread execution, etc.
Hope this helps explain the differences. It's more difficult to say when to use each, but generally I use the rule of thumb that if it's user interaction that raises the event, use a command for anything else, use EventAggregator.
Hope this helps.
Additionally, there is one more important difference: With the current implementation, an event from the EventAggregator is asynchronous, while the CompositeCommand is synchronous.
If you want to implement something like "notify that event X happened; do something that relies on the event handlers for event X to have executed", you either have to do something like Application.DoEvents() or use CompositeCommands.