[bobatsar]

As described in #708, the mobile platform builds every log message, including the string interpolation, before the logger checks its level. Logging therefore costs CPU time even with LogLevel.none (the default), which is noticeable with high-frequency notifications.

Log calls now go through a private getter that returns null for LogLevel.none, so the null-aware ?.log(...) call skips building the message entirely.

No public API change: existing code keeps working, and the example app's verbose-logging toggle already covers both levels, so the example needs no update.
Unit tests added for both log levels.
This replaces the earlier approach of making the logger nullable (see the discussion below).

[Taym95]

if you set logLevel to LogLevel.none you will disable logs

[bobatsar]

Even when setting the logLevel to none, the ressource hungry string interpolation happens. Please reopen!

[Taym95]

can you please updated example app?

[Taym95]

Thanks a lot for contributing, and sorry for closing it. I double-checked, and indeed it uses quite a lot of CPU time. Please update the example app and let's merge this one. It will be available in the next version.

[bobatsar]

Ok, I will have a look at the example app.

How should the behavior be in the example app?
Logging completely disabled or how should I change it?

The example app still works as it is with the old behavior (_debugLogger is initialized to DebugLogger).
To disable the logger (my PR) one simply has to call e.g.

final _ble = FlutterReactiveBle();
_ble.logger = null;

[bobatsar]

@Taym95
In my opinion the disabled logger should be the default (to make sure no performance is wasted in the logger) and only when enabling it manually it should be started.

Otherwise all users have to disable it to get the best performance.

This woul mean some more changes in the code and the example.

What is your preferred solution?

[Taym95]

@Taym95 In my opinion the disabled logger should be the default (to make sure no performance is wasted in the logger) and only when enabling it manually it should be started.

Otherwise all users have to disable it to get the best performance.

This woul mean some more changes in the code and the example.

What is your preferred solution?

It makes sense, but some people are already using this. Functionality will stop working for them when the update happens

[GoodOldBatman]

Does anybody know why this PR is stuck on "BuildExpected — Waiting for status to be reported" ? I would still appreciate this PR.

[bobatsar]

@Taym95 I've reworked this based on our earlier discussion and rebased it onto current master. Instead of a nullable logger, log messages are now only built when the level isn't LogLevel.none. There's no API change, so existing users aren't affected and the example app doesn't need an update. Could you approve the workflow runs and take another look?