Android Question log() output still functions in release mode

[Woody]

I know this has come up before.

It seems that log() statements are compiled in 'release mode'. I notice, when I run my app in release mode via B4A bridge, the output in the log screen in the IDE. As this must take time, the question is, how do I switch that off? Do I use some conditional compiler statement around the log() statements? Do I remove all logging statements prior to release, or should I not bother at all?

 

[BillMeyer]

Good Day,

Look first if you have this statement somewhere:

    #BridgeLogger: True

If so then that is why you are still getting logs in Release mode.
You do not need to remove all the logs or do conditional release compiling - there is no influence in release mode - so you need not bother.

 

[DonManfred]

Do I use some conditional compiler statement around the log() statements?

#if debug
log(...) ' Logs only in DEBUG....
#end if

 

[Woody]

Thank you both. Indeed

#Bridgelogger: True

was there (left over from an example I reworked) And that conditional compiler statement is also very useful.

 

[Erel]

As this must take time

Sounds like a preoptimization. Unless you are making 10k+ logs at a very short period then the overhead will not be noticed (measure it).

 

[Woody]

I'm showing a couple of variables as new data (8 bytes) comes in, every 10 ms.

You are most likely right that logging is of little influence. However, every now and then I notice slow responsiveness of the app (in release mode with logging enabled and #BridgeLogger set) The log window then updates erratically and keeps on displaying logs for seconds after exiting the app. If I then kill the app and restart B4A things run nice again.

 

[DonManfred]

So you want to update the UI 100 times in a Second? Update the ui every 500ms or so should be enough.

 

[Woody]

The sensor I built years ago for another application updates 100 times a second. That is a lot but I can always go down a little in update frequency if needed. The data out of this sensor places a green ball on a canvas. So far the app does not seem to have much trouble in keeping up, probably because the receive data event fires far less than a 100 times a second. Something I have to check. Twice a second is far too slow for the application in mind.

My first exercise was to see if I could make this BT sensor talk to an app and place this green ball on a canvas, like a spirit level. That (with the help of this forum and a number of examples) works great. Now on to the nitty gritty of making this a robust application

 

[DonManfred]

Twice a second is far too slow for the application in mind.

try 100ms instead then (10 times a second)

 

[Michael Wenning]

I have the same as in 1#: It seems that log() statements are compiled in 'release mode'.
I tried comment out: ' #BridgeLogger: True
tried #BridgeLogger: False
and delete it complete.
Always logging...
I checked "Release (obfuscated)" with same results. I am using B4A Version 8.5 and USB debugging.

Is this a bug? How does this work whithout conditional compiling or delete all loggings?

Thank's and regards
Michael Wenning

 

[DonManfred]

Always logging...

Add a conditional compiling around the LOG lines...

#if debug
log(...) ' Logs only in DEBUG....
#end if

#if release
log(...) ' Logs only in RELEASE....
#end if