Goodbye CIQ_LOG.txt

Well, not really. :) The CIQ_LOG.txt file is being phased out in Connect IQ 3.0, and a new CIQ_LOG.yml file is being phased in as a replacement. The differences aren't significant, but are worth mentioning. As you'd expect, the CIQ_LOG.yml is a YAML-formatted text file. Each crash log entry is separated by three hyphens (---). All of the same data you're used to seeing is still there, and we've added a few additional bits of information. Here is a brief sample of a debug CIQ_LOG.yml from our unit test:

---
Error: Symbol Not Found Error
Details: Could not find symbol some_var.
Time: 2018-04-20T16:26:47Z
Part-Number: 006-B9461-00
Firmware-Version: '8.03'
Language-Code: eng
ConnectIQ-Version: 3.0.0
Store-Id: 5ef6e98c-92ff-41cd-afe3-ddaeb41e1bde
Store-Version: 1
Filename: TEST
Appname: ArrayTest
Stack:
- pc: 0x10000132 File: '/test/apps/StackTrace/source/Test.mc' Line: 57 Function: access_private_variable
- pc: 0x100000ad File: '/test/apps/StackTrace/source/Test.mc' Line: 33 Function: testSymbolNotFound


In release builds, you'd see something like this:

---
Error: Symbol Not Found Error
Time: 2018-04-20T16:26:47Z
Part-Number: 006-B9461-00
Firmware-Version: '8.03'
Language-Code: eng
ConnectIQ-Version: 3.0.0
Store-Id: 5ef6e98c-92ff-41cd-afe3-ddaeb41e1bde
Store-Version: 1
Filename: TEST
Appname: ArrayTest
Stack:
- pc: 0x10000132
- pc: 0x100000ad


The new and interesting bits are that we've added theLanguage-Code, Store-Id, Store-Version, Filename and Appname. The one that seems to stick out is the Store-Version field. This is the version of the app as seen by the app store. For the first version of the app, this would be 1. Every time you upload a new version that value would increment.

Also, the Filename is base name of the actual file on the file system excluding the path and extension. In the above example, the application file is /GARMIN/APPS/TEST.prg, so the file base name displayed is just TEST. For apps loaded from the app store this would typically be some gibberish string value. If you wanted to enable println() logging for an application, this would be the base name of the file the user would need to create in the /GARMIN/APPS/LOGS folder.
  • So indeed nothing really exciting, though the filename bit is quite handy when needing to debug (which I still find quite cumbersome when ppl have issues, any relevant info in tthe ciq_log would be EXTREMELY helpfull...but I assume that's simply not really possible)
  • The change to YAML isn't an arbitrary change--we have some plans to do some things with the crash logs in the future that should make them more useful for you. For my part, having info like the time stamp and part number (i.e. the device) will be immensely useful. At this point, we just didn't want people to get confused when the CIQ_LOG.txt file they're used to seeing isn't there anymore. The Programmer's Guide will be updated with the details, but that won't be available until 3.0 comes out of beta.
  • I agree Brandon, lots of useful stuff! Just the appname instead of just the store id if there are things for different apps in the file! Also the FW the user is running, and by part number, if it's an APAC device. Things I usually have to ask.

    One question though - Store Version - is that the number of times the app has been uploaded, or is it the version we set (like "2.23") when we update the store? If it's the number of times it's been updated, is there any way in the app store to see what that is for our own apps? Maybe show it in "edit details" for the app like Manifest ID is shown today?
  • The Store Version is essentially the number of times the app has been updated. It's a version we store behind the scenes that's independent of the one visible on the store. I'll ask the store team whether we can display it in the app details on the developer dashboard. (I'm certain possible.) It's more meaningful to us, but I could see some utility for non-Garmin developers, too.
  • Brandon, as a specific example, if I get a ciq_log with a store version of say, 25, and by way of the dashboard could see the store version there is 28, I'd probably ask the user to update and see if the problem still exists as a first step. That could help to avoid looking for a problem that's already been fixed. (vs a problem I thought was already fixed but maybe not)

  • Having dashes makes me smiling. Thanks! 5ef6e98c-92ff-41cd-afe3-ddaeb41e1bde It is just Ctrl-C now. https://apps.garmin.com/en-US/apps/ + ID. Next step is auto submit crash logs to developer's account.
  • I noticed that the developer dashboard for our apps now reference the internal number to make it easier to correlate to the new CIQ_LOG.yml. Looking forward to the new app store roll out.
    • Version: 3.2 (Internal: 36)

    • Yes, I noticed that the other day. I'm looking forward to the yml version!
    • The Store Version is essentially the number of times the app has been updated. It's a version we store behind the scenes that's independent of the one visible on the store. I'll ask the store team whether we can display it in the app details on the developer dashboard. (I'm certain possible.) It's more meaningful to us, but I could see some utility for non-Garmin developers, too.


      By the way, is this "internal version" the number which the "IQApp" instances of the Android and iOS mobile SDKs are supposed to return?

      If so, I find it curious that you kept it behind the scenes, as it is certainly very useful for non-Garmin developers ;-D

      But if it is not - and I wouldn't be surprised if it isn't, because the mobile SDK should also work for apps which aren't on the store, right? -, what is this version in the "IQApp" class? It is an integer on Android and iOS, and the version names we set ourselves are strings.

      (I'm talking about the "IQApp" classes mentioned in
      Section "Working with Apps"
      on https://developer.garmin.com/connect-iq/programmers-guide/android-sdk-guide/
      and "Requesting an App’s Status"
      on https://developer.garmin.com/connect-iq/programmers-guide/ios-sdk-guide/)

      PS: Maybe I should have simplified my question and started a new thread:
      What is the "version" returned by the "IQApp" instances of the Android and iOS mobile SDKs
    • I am about 90% sure the IQApp.getVersion() value is the internal store version number, but I'm going to confirm that (the mobile SDK documentation is admittedly poor). In this case, you're right--this version number would be very useful, and I'm not sure why we decided to obscure it in the past.