You are reading a single comment by @halemmerich and its replies. Click here to read the full conversation.
  • There are functions in the GPS context that would do well and be useful in a module, for example compass noise filtering, handling access to track data more encapsulated, "sensor fusion" between compass and GPS and lots more of smaller things that could be useful outside of their apps. Some refactorings in this spirit I would like to do to GPS Trekking.
    When developing for the Bangle, there are some tradeoffs to make. One big part of the execution time is actually parsing the javascript text. So the "form" of your code directly influences execution speed. I have written Imageclock and learned the hard way how expensive function calls and verbose code are. In there I started with recursively parsing JSON and rendering that as a watchface. That was so slow that watchfaces with seconds just weren't possible. "Flattening" that tree of watchface components in the browser and generating the rendering code for the Bangle got that several times faster for some watchfaces. It was calling exactly the same rendering code for the elements, just no longer recursively traversing the JSON saved that much execution time.
    Another example would be the Layout module. It's great for easy creation of layouts, but if you need to refresh often or are doing memory intensive stuff otherwise you will probably run into problems with either speed or RAM usage. That's not to say Layout is not a great module, I try to use it whenever possible. But it shows that on a platform this constrained there won't be a way to make every code nice and tidy, sometimes getting to the edges of available resources means ugly code or hacks to even get it to work at all.

About

Avatar for halemmerich @halemmerich started