Enable debug - user friendly creation of LOGS/...txt files

Developers sometime need feedback from customers, so logs are needed.
Logs stored in /Garmin/APPS/LOGS, but customer needs to create an empty text file and put proper name that corresponds to the application name, like for 88833555.PRG is 88833555.txt should be created.
This way is difficult and not user-friendly.

I propose to embed following solutions:
- Garmin can create in Garmin Express a setting "Enable debugging tools for CIQ apps". When checked, appears an additional setting near each app, like "Submit debug logs". Express knows about file names, so can create proper log file. After logs collected, Express packs them, and then these can be automatically mailed to the developer via Garmin servers (app has an origin and tied with developer's account via email).
- Garmin can share information about web-server requests (server accepts file name, returns developer ID and application ID with name). For example somebody (like me) can write client app for Win/MAC, that shows friendly names for apps, and enables logging by creating proper .txt files in LOGS folder. Finally, after logs created, app can provide it as text file for customer on desktop (or even email).
- Developers should embed in apps their names with the specific global text string with tags (ie. "<APPDEBUGNAME>MyCoolName</APPDEBUGNAME>"). Utility can scan binary .prg files and show human readable names, that match .PRG, then create proper .txt for logging. This is not reliable way, but if major developers start supporting this variant, it can live.

Personally I vote for variant with Express.

HermoT over 8 years ago

This is a really good suggestion!

I’d like to piggy back on this suggestion and also ask that in a similar fashion, GE or GCM should provide the option per app to reset it’s settings or clear it’s data.

There often is a need for users to revert to a fresh state, and it would be easier to do this through GE or GCM than telling a user which files to delete (APPS\SETTINGS and APPS\DATA). The problem is that it is difficult to tell which of these files belong to a specific app (due to the random file names), and a user often has to delete them all (after backing up) to ensure that the settings / data file was deleted, and then copy the rest of the backed up files back.

So I think the originally suggested solution can help solve a lot of other issues and add value to CIQ in a consistent way.

danielp27 over 8 years ago

Developers sometime need feedback from customers, so logs are needed.
Logs stored in /Garmin/APPS/LOGS, but customer needs to create an empty text file and put proper name that corresponds to the application name, like for 88833555.PRG is 88833555.txt should be created.
This way is difficult and not user-friendly.

I propose to embed following solutions:
- Garmin can create in Garmin Express a setting "Enable debugging tools for CIQ apps". When checked, appears an additional setting near each app, like "Submit debug logs". Express knows about file names, so can create proper log file. After logs collected, Express packs them, and then these can be automatically mailed to the developer via Garmin servers (app has an origin and tied with developer's account via email).
- Garmin can share information about web-server requests (server accepts file name, returns developer ID and application ID with name). For example somebody (like me) can write client app for Win/MAC, that shows friendly names for apps, and enables logging by creating proper .txt files in LOGS folder. Finally, after logs created, app can provide it as text file for customer on desktop (or even email).
- Developers should embed in apps their names with the specific global text string with tags (ie. "<APPDEBUGNAME>MyCoolName</APPDEBUGNAME>"). Utility can scan binary .prg files and show human readable names, that match .PRG, then create proper .txt for logging. This is not reliable way, but if major developers start supporting this variant, it can live.

Personally I vote for variant with Express.

Good idea, i totally agree
+1

VivoactiveHRGuy over 8 years ago

The thing I have the biggest issue with here .. is that the name of the PRG changes all the time if there is a version upgrade.

The above .. where it combats this issue, would be a great thing. So if it eliminates the issue, it has my vote. :)

That is a huge issue for users .. as then nothing works. I would love the ability to have a set name for the text file, where the name of the prg would not change for the life of the application. There is no need for the name to change, there is no benefit in doing so.

jim_m_58 over 8 years ago

I like Hermo's idea about reseting things. It would really just be deleting the .set/.str if the app wasn't running, and they get recreated the next time the app is run. (Actually, maybe just kind of a subset of what happens when a user uninstalls an app?)

For the log, having an easy to generate .txt may be an issue, as apps could then use it for just general "user data" saving of info. Writing to mass store is expense, and not something to encourage.

Maybe a common name (like APP_DBG.txt), that's used by any/all apps to save debug info? (and maybe something like Sys.debugln() in addition to Sys.println()?) Easy to tell a user what to create, and easy for a user to find and email (like CIQ_LOG.txt today)
When writing, either the developer or the VM includes something to ID the specific app?

Coleman.Apps over 8 years ago

Hey Everyone,

I have set up a request for the team to discuss this as a new feature. I will give fair warning that this would touch on several different teams and takes a little more buy in than the usual ticket, but I will do my best make your voices heard! :D

Thanks,
-Coleman

VivoactiveHRGuy over 8 years ago

As someone that uses the .txt file a lot in my apps (for logging of summary data for users use), the whole it being expensive is to some of us irrelevant. However .. if you managed to get the Garmin store to stop changing the file names when an upgrade is done, that would likely please many .. mostly the users.