7

GoogleConversionPlugin insists on logging random bits of useless information and screwing up my automated testing reports.

Kirby Todd
  • 11,254
  • 3
  • 32
  • 60
  • 1
    checkout the answer to [this question](http://stackoverflow.com/questions/4332041/how-do-i-redirect-all-errors-including-uncaught-exceptions-nslog-calls-and-ot), sounds like you can redirect NSLog to something else, maybe you can have a method which filters for some google related string? – wattson12 Jan 28 '13 at 14:21
  • What about just filtering the messages from your test report? – Sulthan Jan 28 '13 at 15:03

2 Answers2

3

You can redirect all NSLog() output to nowhere (or to a file other than the console log) or make it call your own logging output function (not officially but it works), however this will act on all NSLog() calls, not only on calls from this Google Plugin, also on calls from within your code. If your app is single threaded, you may get a way with your own logging function checking a global BOOL whether logging is currently enabled or disabled; yet in a multi-threaded environment, you would have to control that per thread (and if you use GCD you are multi-threaded even if you don't deal with threads yourself), which is also possible, albeit a bit more extra code.

So the question is, is it a useable to solution for you to disable logging globally (or for the current thread), make your plugin call and then turn it back on again? Of course, disabling per thread will not work if the plugin is multi-threaded internally (it may switch threads without you noticing), but in that case the global switch would still work.

Controlling only the NSLog() calls of a static library is not possible unless you are willing to "patch" this library (and you are allowed to do so without having Google sue you, of course). It would be possible for a dynamic library, but as you develop for iOS, you cannot use dynamic libraries.

So let me know which of these possible solution suits your needs, if any, and I will see what I can do for you (e.g. update the answer and add some code or instructions).

Mecki
  • 125,244
  • 33
  • 244
  • 253
  • 2
    "make it call your own logging output function (not officially but it works)", yes that! Hopes go up but then there are no details :( – WiseOldDuck Jan 14 '14 at 21:11
  • @WiseOldDuck The question was not specifically about redirecting NSLog calls as a whole but whether it is possible to selectively do so (and the answer is: It isn't). That would be a different question. See here http://redir.ec/RFVGY This will only work for NSLog calls. To also catch printf-calls, you can create a file handle of your choice and swizzle it with `STDERR` and/or `STDOUT`, see http://redir.ec/3lz1S (just ignore the fork, you can also do this with your own process without forking it first). If you open `/dev/null` as file and redirect output there, log messages go nowhere. – Mecki Jan 15 '14 at 19:08
0

First of all "You should contact and file a bug with the developer of those library/ frameworks".

In release versions debugging, errors, or any NSLog etc must not be there unless it is very critical.

Anoop Vaidya
  • 46,283
  • 15
  • 111
  • 140
  • 7
    Says who? NSLog is for logging, any logging, not just for debug log output (otherwise it would be named `NSDebugLog` or the like). So who says NSLog output must not be in release versions? – Mecki Jan 28 '13 at 14:30
  • 2
    @Mecki: I worked with apple for more than a year, I was strictly advised in code-review not to use NSLog in release version. So i always use conditional nslog. – Anoop Vaidya Jan 28 '13 at 14:36
  • Is there anywhere this is published or is this just an apple internal guideline? the console for my device has plenty of logs in it at the moment... – wattson12 Jan 28 '13 at 14:36
  • We have currently a couple of apps in the Mac App Store also in the iOS App store, and they all use `NSLog`, not extensively, but even a normal app start up triggers a couple of these and they all passed review without any problem. I just re-read the app store guidelines for iOS and Mac and I cannot find any statement about restrictions on logging. – Mecki Jan 28 '13 at 14:38
  • NSLog slows the process, I dont know about ios, but as an Mac OSX developer, i never leave NSLog. It slows down the application, as much of the time is taken on printing to console rather than processing important tasks. – Anoop Vaidya Jan 28 '13 at 14:38
  • @Mecki: Now you only say, if the big boss asks me to remove nslog in codeview session, shouldn't I? and a service call was reduded from 7 seconds to 2 seconds just by commenting all nslogs!!! – Anoop Vaidya Jan 28 '13 at 14:41
  • its good advice to get rid of logs you don't need, and DLog() is good for that, but for errors and warnings it should be fine to leave them in – wattson12 Jan 28 '13 at 14:42
  • 3
    Yes, NSLog slows down a task, maybe by 1 millisecond per log line, so you should probably not use it extensively and not in critical pieces of code. But saying it is a bad idea to overuse NSLog or use it in critical sections, is not quite the same as saying "it must not be there", which means it is forbidden. Maybe it is forbidden in your company or you consider it forbidden for yourself, but fact is, it is not forbidden, at least not by Apple. – Mecki Jan 28 '13 at 14:42
  • I was developing an application for apple itself, they use it for themselves. they asked no nslog. why error will be shown in nslog? show it to user, no need to hide from user. Anyways, its upto we, what to follow what no to. :) – Anoop Vaidya Jan 28 '13 at 14:47
  • @AKV: The reason you were asked not to use NSLog may have been because you were over-using NSLog. As @ Mecki points out (perfectly), there are many reasons why it's a good thing, there are places you should NOT use it, and it's definitely not forbidden (and is present in numerous Apple apps, BTW. Check your system.log) – James Boutcher Jan 28 '13 at 15:00
  • 3
    I don't mind libraries logging to NSLog if it's configurable and I can turn it off somewhere. It is in my opinion bad form to release a closed source library with debug logging in it. – Kirby Todd Jan 28 '13 at 15:10