Detect simulator

Btw, the very first thing that Garmin recommends for “How To Test” is....

https://developer.garmin.com/connect...e/how-to-test/

How To Test[/B]

Connect IQ has a couple of different methods for testing and debugging your apps:

• Basic debugging with println() statements
  
• Run No Evil unit test framework
  

That's not been updated since the debugger was introduced.

Fair enough. But you could forgive anyone who’s new to CIQ for taking that advice as-is....

Yet many ppl in the real world still use printlns (or strace) on various platforms where a robust and fully featured debugger is available. I’ve tried both and each has their place.

I mean, why do people use strace at all? Surely you could simply debug the same application and put breakpoints at all the system calls you were interested in....

Would’ve been nice if there was a release vs debug annotation for ciq (please don’t tell me there is >_>)

There is.

using Toybox.Application;
using Toybox.System;

(:debug) function print(message) {
System.println(message);
}

(:debug) function printf(format, args) {
System.println(Lang.format(format, args));
}

(:release) function print(message) {
// do nothing
}

(:release) function printf(format, args) {
// do nothing
}

class TestApp extends Application.AppBase {

function initialize() {
$.print("AppBase.initialize()");
AppBase.initialize();
}

// ...
}


The disadvantage is that the parameters passed are still compiled and evaluated, which means cycles and memory are wasted.

ppl in the real world still use printlns (or strace) on various platforms where a robust and fully featured debugger is available

There is a good reason to use strace; it works without debug information. That said, all it really does is show you system calls.. which means you can't see any internal application state.

Thanks Travis.ConnectIQ I saw that coming....

I should've believed the second post.

I guess I'll stick with my manual insertion of debug statements or horrible conditional compilation.

Yeah I do realize that strace is not really the same as printlns or a substitute for proper debugging. It's actually really useful for helping pinpoint the approximate spot of app crashes sometimes. And of course it's often used on release execs with no debug info.

But when I started working as an embedded dev, one of my first tasks was to set up remote gdb on the new platform and teach everyone how to use it. I wrote a guide, held a mini seminar and guess what?

Within days everyone was back to using syslogs. Again, these are devs of all skill levels.

Right or wrong, logging to the console is just easier.

There is.

using Toybox.Application;
using Toybox.System;

(:debug) function print(message) {
System.println(message);
}

(:debug) function printf(format, args) {
System.println(Lang.format(format, args));
}

(:release) function print(message) {
// do nothing
}

(:release) function printf(format, args) {
// do nothing
}

class TestApp extends Application.AppBase {

function initialize() {
$.print("AppBase.initialize()");
AppBase.initialize();
}

// ...
}


The disadvantage is that the parameters passed are still compiled and evaluated, which means cycles and memory are wasted.

perfect! exactly what i was looking for. I agree that in the final version released to users all these statements should be removed. But now i have an almost unusable app in the testing phase on my FR630 if i include a lot of println statements (app becomes very slow!). So in the testing phase this will save a lot of work of removing and re-adding println statements everytime i switch between simulator and real device.

BTW: The real problem is that i found out that a lot of code which runs perfect in the simulator gives errors on the real device (out of memory, unhandled exceptions, animation which does not work, etc...) so that's why i have to switch a lot between simulator and device...