Debugging

I find the Garmin development environment seriously broken.  

When simply running an app on the simulator there is inadequate or even no error information following an unrecoverable error.

When attempting to debug:

  • I am often inexplicably unable to set breakpoints, even ones that had worked in the previous debug cycle.
  • The simulator frequently crashes requiring forced closure.
  • Eclipse is often left in a state where it will not close without forcing this.

I have reinstalled Eclipse and the Garmin plugin on numerous occasions now without improving things.

The development cycle is the most frustrating and inconsistent of any that I have previously developed on.  Android development tools are infinitely superior and indeed allowed me to reverse engineer your Android SDK, the documentation of which is hopelessly out of date and misleading.  I don't believe any software engineer would be content with such a mess.  This must be a failure of Garmin management. 

Top Replies

All Replies

  • Which SDK/plugin are you using? What platform?

    I admit, I don't use the debugger in eclipse that often, as I find a well placed println can be faster/easier., plus with them you can collect info running on a device, for those things that are easier to reproduce on a device itself..

    I've been doing CIQ for 4 years, and while I've seen some of the things you mention, it's a very rare occurrence. (a vanishing sim comes to mind)

    File bug reports for the specific things you find.That way Garmin will look into them

  • I download and use the latest SDK when notified and regularly check for updates to the plugin.

    SDK 3.0.12

    The Plugin rather rudely does not display its version number in the installation manager but is updated when notified of a new version.

    I use the latest version of Eclipse:  Eclipse IDE for Java Developers, Version: 2019-03 (4.11.0), Build id: 20190314-1200

    You are lucky.  I have these problems multiple times during any development period.  Are you developing in a Windows based system?  I am on a Mac and wonder if the tools are properly tested on other platforms.  

  • To find the plugin version, in eclipse,  do Help>About Eclipse>Installation Details.  In the sim, you can see the SDK version with Help>About.

    I use windows (have done so with CIQ for 4 years), but I know a number of people who use Macs including some of the people at Garmin.  What you're seeing isn't typical.  As I said before, you may want to post your issues in the bug report area.

  • All of the things you described also heappen regulary to me. I am using Windows 10, however, so the bugs must be platform-independent. Also println's often just don't show up on my console and println's in a loop usually crash my simulator (so I have to force-close it).

  • The apparent hang when using println issue has been around for a long time, and was fixed with the 3.1.0.beta3 SDK. There was also an issue when using background processes that would cause the println output to not appear in the Eclipse console. That was fixed as well.

    https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/sdk-release---3-0-12-and-3-1-0-beta3

    General Changes
      * Fix issue that caused System.println() and System.println() to stop working after a background process had exited.
    
    Simulator Changes
      * Fix apparent simulator hang seen when using a many calls to System.print() or System.println().
      

  • I couldn't agree more with  post. It was really surprising to see presentation on CIQ Summit about some upgrades in debugging while for every developer around me, it simply doesn't work at all most of the times resulting that nobody is using it to prevent frustrations.

    Jim, I respect your contribution to this community, but according to some of your recent posts, I just get feeling that you belongs to some lucky dev group who for some reasons doesn't experience issues like most of others. Is it because you are part of the community from very beginning and simply overlook some problems as you are used to solve them via some undocumented workarounds unknown to new members? 

    I really don't want to have "hater sticker" on my name here. But while I really like potential of this platform and would love to see it more refined, I must admit, that I am unable to post bug reports to every issue I encounter because of the feedback to these reports and chances for bugs to be solved. Because problem is not about particular bugs here, but clearly about organisation of whole platform development . With this approach, it is not surprise that there is so low number of developers working on actual business projects with bigger complexity. 

    BTW, I am using Windows 10, Eclipse and CIQ 3.0.12 now.

  • Jim, I respect your contribution to this community, but according to some of your recent posts, I just get feeling that you belongs to some lucky dev group who for some reasons doesn't experience issues like most of others. Is it because you are part of the community from very beginning and simply overlook some problems as you are used to solve them via some undocumented workarounds unknown to new members? 

    It can really just be summed up as experience and at times, knowing what to avoid.  I have a basic work flow that works most of the time (how I run/test things), and others may do it differently  I have been here since the beginning, and over the years, kind of know what to look for, and at times the "fix" can be as simple as restarting the sim and/or eclipse.  I also follow what others run into, so I know what to look out for and maybe try to avoid.  You do tend to pick up a bunch of tricks when you do 50+ production apps and maybe another 100 that are for testing!  Slight smile  

    I also don't use things like RNE or the debugger.  Not because they are broken (as far as I know), just that I tend to debug with println calls and even then use them very sparingly and remove them when I don't need them. And that gets back to my workflow.

    One trick I do use involves the SDKs - I always update as soon as a new one is available, but I also keep the last 1 or 2 around so I can switch if I run into something.  And since the summit, I've been doing that with both 3.0.x and 3.1.x,  Since the summit, I've been using 3.1.0 as much as possible and only switching back to 3.0.x for things like exporting a .iq or if I run into a SDK/sim bug.  

  • Thank you Jim for your response and tips!