App debugging

Hello,

I am the author of the Badminton Score Tracker app (https://apps.garmin.com/en-US/apps/51606451-57e2-4f99-9420-2ba5a80b5df6). As you can read on the reviews, a lot of my users are reporting that the application does not work: they say that it only shows the "IQ logo".

It works well on my own watch and on the simulator as well. I have never encountered this kind of problem with other apps from the store so I have no idea of what the problem looks like.

First, how is it possible that the behavior of the app is different on different watches (my app is only compatible with Fenix 3 for now)? Is there a global setting that way affect the way an app runs on some watches? Can I somehow retrieve a log from the impacted users or something that can help me to debug the app (like what is available on Android Play Store).

Second, the code of the application is available on Github here: https://github.com/matco/badminton/tree/v1.2.0. Is there someone here who knows what the issue could be?

Thanks.

HermoT over 9 years ago

Have you side loaded it or installed to your watch from app store?

I have found in past that a side loaded app my work, and then I upload to the store, only to crash when freshly installed from app store.

Clean and uninstall from your watch and try install from store as if you were one of those users.

Do you have user settings in your app?

matcora over 9 years ago

I already tried to install the application from the store and it works as expected. I side-loaded the app many times during its development so I had to remove manually the .prg file from the file system of the watch before installing the app from the store. Maybe there is some other file elsewhere that should be deleted as well.

I have reviews from people who are asking for new features so I know the app works for at least some users.

The app has no user settings.

travis.vitek over 9 years ago

It is possible that they are using old firmware? You can do something like this in your app at startup...

using Toybox.System as Sys;

using Toybox.Lang as Lang;



function dump_device_information() {

  var deviceSettings = Sys.getDeviceSettings();

  

  

  if (deviceSettings has :monkeyVersion) {

    Sys.println(Lang.format("MonkeyC Version: $1$.$2$.$3$", deviceSettings.monkeyVersion));

  }

  else {

    Sys.println("MonkeyC Version: < 1.2.0");

  }



  if (deviceSettings has :partNumber) {

    Sys.println(Lang.format("Device Part Num: $1$", [ deviceSettings.partNumber ]));

  }

}

If you have the user create a log file for your app as per the instructions in this post, you should get some output about what device they are running and what version of MonkeyC is supported. You can also litter your code with println() calls; the output will be sent to the file. Then when it crashes, you can get the user to send you the log files (CIQ_LOG.txt and {APP_NAME}.txt). You can often figure out what the problem is with this data.

Travis

matcora over 9 years ago

I didn't know the log feature. Thanks for the tip!

But the real problem is there is no way to interact with your users. You can give a link to an issue tracker (like on the app Github page, or the app "showcase" thread in this forum) in your app description page on the store, but there is very few chance that someone takes the time to report his problem. It would be nice to be able to reply to a review to invite the user to do a real bug report. Then maybe you will get the user to send you a log.

Also, maybe it would be a good idea if users could send the log to Garmin servers when the application crashes. Then, gather these reports and put them on the administration page of the app.

Brandon.ConnectIQ over 9 years ago

We actually already collect device crash logs, which are analyzed by the device teams from a high level to look for common crashes. I like the idea of collecting app crash logs and providing that data to developers, but there are two hitches to that preventing us from just making it happen:

1. The CIQ_LOG is a general log for CIQ, and doesn't differentiate between apps in the log. App specific logs only capture println() output added by the developer to their app, so may not be much benefit in debugging a crash unless very carefully designed.
2. Release app builds don't always provide a ton of useful debugging information because the PC-to-line number information is not included.

I'm not saying these items can't be addressed, but we'll need to think about better ways to leverage logging to make debugging crashes in the field easier for developers. It does sound like a very good tool, especially since most developers don't have a full collection of hardware with which to test. Thanks for the suggestion!