FEATURE REQUEST: Access to storage outside of app

You can also add it to the fit file (fitContrib) if you are recording and get the info off the watch that way.  There are problems with using a log file, with one being the name. as it's based on the store assigned name of the prg file (If I download your app, I'll have to use a different name than if you download your app).  Then you have the complications of MTP devices with the need for something like ATP to access the device on a mac.

As far as accessing storage from something else, Brandon put in a feature request for that, because it's been requested so often, but there are wrinkles in that dealing with security and GDPR.

forums.garmin.com/.../allow-shared-storage-between-apps

Thanks Jim. My fit file is already overloaded and hitting problems adding more entries. Also the data is sub-second resolution (which matters in this case) and FIT captures every second - though I could "package" up samples. However, fit writes are asynchronous to the capture and there are no methods to sync them - like a data needed trigger from the fit class.

You don't want to write anything to the file system sub second, be it with println or using storage, as things like that are slowwwwwwwww,,,  In the case of println or something similar, you also are dealing with the max size of the files where they automatically wrap.

If you are just writing subsecond data but not at subsecond speed a 32 bit value can go a number of days before it wraps.  timerTime is in milliseconds for example and 32 bit, and with the FitSDK, you can write your own app to get the data from a fit file.

As far as how much fit data you write, you could already have an issue if a second DF that writes fit data is involved, where your app or the other app run into issues involving the 2nd app.

Hi,

I am writing the data out as the app stops as then not time critical. It's an array of 1500 elements (or a corresponding string representation). I wouldn't want to write sub-second :-)

On the FIT sync question if my data changes more than once a second (n times) I have a jitter in sampling of +-n/2 samples

I could nominally add a bunch of session string fields but would both run into field size issues and also errors being thrown of execution due to a limit on the number of fit fields allowed to actually be created.

The text files are limited to 8k, and wrap when full, so with 1500 elements they must avg under 6 bytes each (with no lf/cr or seperation characters or the files may wrap with the data spread across the txt and bak files,  And they probably will anyway unless you re-create the txt file before each usage.

that's what I do at the moment but it's both hard to use to get back test data from users and there's no other separate output channel. eg being able to write to "file" rather than console/app.txt file.

I’m pretty sure Garmin isn’t going to provide file writing. I suggest that you reconsider a web API.

How many subsecond parts?

Save the subsecond data and write it out every second (your “package up” idea.

You probably don’t want to write to “disk” multiple times a second.

Wouldn't know where to start on that. Assume I would need to host and build a website which I then "put" data to...