Logs strategy - Libs? Manual?

Former Member over 7 years ago

Hello everybody.

I'm just slowly but securely advancing on my journey of connectiq-apps development and I'm starting to reach some limitations of just using basic language features.

One of the things that is starting to become cumbersome is logging. System.println is handy for some basic logging but it is already too basic.

First because you lack context (timestamp) and because you will need to comment out the log lines when reaching production.

I'm curious to know which strategies do you use. Do you use the logging barrel provided by Garmin? Do you just use and comment println statemens? Do you have a custom solution?

Also I'm wondering how much "resources" does logging consume. For example, I doubt that my 3~5 lines of logs that happens every 5 minutos on my background service it has an impact, but who knows, this is all new to me. I am used to servers programming where this kind of things are not a problem.

Thanks for your comments

jim_m_58 over 7 years ago

There is LogMonkey (https://github.com/garmin/connectiq-apps/tree/master/barrels/LogMonkey), but when it comes down to it, it's doing println calls. The <appname>.txt file is all there is to log to. And note, it's also limited in size to 8k, and when it reaches the max, it becomes a .bak file, and another 8k can be written (so you can get up to about 16k).

Writing to the file system is not cheap, so you want to only log things sparingly.

And you can control what gets logged by using things like the :debug annotation, though I tend to just comment out the lines sith Sys.println() calls.

":debug

Code blocks decorated with this annotation will not be included in release builds at compile time."

I know of apps where by way of an app setting, an alternate screen with debug info cn be showen when running on a device, and something like that can be used.

but as far as basic logging, it all gets back to println() calls.

Former Member over 7 years ago in reply to jim_m_58

Thanks for your response jim_m_58

Yep, I was aware of LogMonkey, which seems to be the only alternative.

What I want to avoid is: Having to comment out and comment in log lines. It is inconvenient to have to change the source code to get some logging and also I'm worried about forgetting about commenting some log lines. I prefer something that does it automatically.

I am not sure how the debug annotations work. I know log-monkey strips debug lines when you compile the release version of the app but, how does it behave? You still do the function call and then it does nothing or all references to them are completely stripped out?

jim_m_58 said:
Writing to the file system is not cheap, so you want to only log things sparingly.

Yes, for sure. But I'm making web request on background and there are lots of things that can go wrong there, and being able to trace the problem down is key. However, I want to minimize the impact.

jim_m_58 said:
I know of apps where by way of an app setting, an alternate screen with debug info cn be showen when running on a device, and something like that can be used.

That is interesting too. The negative part is that you are including all the code, but since apps are already very small I don't think that is a problem. Maybe I can make something like that for background processes by subclassing.

For now I have an average of 8 log lines every 5 minutes, which is probably ok.

Thanks for sharing your experiences.

jim_m_58 over 7 years ago in reply to Former Member

Typically, logging is something that's done by a dev with a sideload, and not something that users would do. And a big part of the reason is that the name for the logfile isn't that easy to determine. With a sideload of myapp.prg, the log would be myapp.txt, but when downloaded from the store, the app would be called <some 8 character name>.prg, and that name isn't consistent from user to user.

And I know that some apps, do leave the printlin calls in for a production build in the event they are needed, as with no .txt file, their impact is less (nothing is written).

When it comes to something like a background process with makeWebrequest calls, what I do is if the call was a success (return code=200), I return data, and if not, I return the error code, and then in onBackgroundData, I use "instanceof Number" to see what it is. If it's an error code, the widget/WF/etc can act upon it - maybe display an error if there's no comm connection, no known location, a missing APIkey, etc.

So, in a background, the callback for makeWebrequest is something like this:

	function receiveWeather(responseCode, data) {
        if (responseCode == 200) {
            Background.exit(data);
        } else {
		    Background.exit(responseCode);
		}
    }