File Not Found Error

I noticed that the Crystal watchface also crashes with "File Not Found":
https://apps.garmin.com/en-US/apps/9...7-17cfa0f0081b

---

There's a lot more I wanted to say, but I don't want to derail the thread too much (sorry @StachuMan). I'll just that there's a lot of different levels and aspects of coding, including coding apps on the backend and coding network protocols, where hex is essential. Hex is essential in the Garmin ecosystem just to look at FIT files. Or in any network system where you're looking at low-level data or dealing with things that have to be efficient or high-performance.

I also use hex all the time in my Monkey C apps to optimize things down to the last byte. Nobody taught me "why hex is important" in a classroom, I learned it on my own. And I know some professional engineers with 35+ years of experience who don't have basic computer science knowledge from first year university which would've allowed them to avoid making mistakes in writing incredibly inefficient code that others who care about CS have to fix. Then again, there are also CS profs who couldn't write decent code to save their lives, so it works both ways.

IMO, a good coder has a balanced mix of theoretical and practical knowledge. Ironically, being comfortable with hex is an example of a very practical skill in coding, imo.

FlowState Please, let's continue this discussion in a new thread. I glimpsed some of your longer thoughts before you edited them out, and I think there's a lot more to be valuably discussed the subject.

RaceQs TBH it's not that important. It's my fault for getting triggered over something so trivial. Sorry about that.

I realize in my original post I said "decades of computer science". On second thought, I should've probably said "decades of computer engineering". I think engineers care more about hex than computer scientists, to be honest. Pure computer scientists deal more with abstract math where hex vs decimal is not even important.

I'll just say that there are CS profs who can't code and there are engineers who don't understand theory, and I think neither situation is well-rounded. But an engineer probably needs theory more than a prof needs practical knowledge.

A while back I wrote a python script that took the path to api.debug.xml and then prompted for addresses to lookup and translate. With something like this you shouldn't care about the format of the data.

will it run on a Mac? is it available to devs

There is no good reason it shouldn't run on a Mac. It is python, so it should be super portable. I had to add a .txt extension so the forum software would let me upload it.

I had the same issue: "File Not Found" when using Storage.getValue() specifically when located in onUpdate(). "File Not Found" never occurs when Storage.getValue() is in other places, such as onLayout(), onLoad() or onSettingsChanged().
I moved all Storage.getValue() occurrences from onUpdate() to onLoad().
To me, it seems to be a CIQ bug.

@julienvm
You probably don't want to do this in onUpdate for other reasons. You are hitting the file system each time it's called, and that is slow. You want to read it once (maybe in initialize()) and save it off. And then saveValue() if it changes.

See: https://forums.garmin.com/forum/deve...05#post1442205

julienvm
You probably don't want to do this in onUpdate for other reasons. [/URL]

You are right, but the point is we shouldn't be getting a "File Not Found Error" ... EVER!
I don't know if they have traced this, but I had a response to a very similar occurrence and am waiting to find which bug they have actually identified.

True, but I was pointing out what julievm was doing in onUpdate was not the best way to do it ("for other reasons...") Even when file not found is fixed, it's not the best way to do this.

Thanks guys, I didn't realize accessing the storage caused such a lag, on a per request basis. I will try and optimize.
That leads me to think that there is no official documentation on performance. I'd love to be able to see what's the execution time impact of the different tools (not just storage, but everything), as otherwise it's quite cumbersome to do it scientifically at home.
Thanks again for your feedback though, really helpful.