Avatar for halemmerich

halemmerich

Member since Jan 2022 • Last active Sep 2022
  • 4 conversations
  • 81 comments

Most recent activity

  • in Bangle.js
    Avatar for halemmerich

    In my sensortools I override the .on and .removeListener methods, but that is only for debugging purposes. I suspect too much overhead to do that in possibly multiple libs.
    Maybe a fast low level function to get all listeners for specific event and a small module in js to handle storing/restoring them would work and be flexible enough.

  • in Bangle.js
    Avatar for halemmerich

    This seems very cool. Does this clash with other apps using the setLCDOverlay or would the widgets just no longer be displayed if for example another app shows notification with this method?

  • in Bangle.js
    Avatar for halemmerich

    Actually I got the widgets to render and behave mostly as expected. There is still something strange going on. Imageclock always loads the widgets and then replaces the draw functions with functions doing nothing and restores them as needed (showing the widgets/switching to launcher). Essentially that hinges on a showWidgets variable, which should be false on every initialization, but the widgets visibility survives the switch between clock and launcher. Widgets shown on clock are still shown after switching to launcher and back.
    I would expect the showWidgets variable to be removed and reinitialized to false, since it lives in the block scope. The memory after GC is always the same for launcher and clock, so probably no major leaks. Launcher uses less memory than clock, as expected.
    The behaviour is actually quite nice, but I don't understand why it works that way. Printing the showWidgets variable at the top of the block does not work, as it is not yet defined.

  • in Bangle.js
    Avatar for halemmerich

    This is absolutely awesome. I had to try with Imageclock and Iconlaunch and hacked some things together to make it somewhat work with this new mechanism.
    Cleanup is not yet complete, Imageclock uses a lot of timeouts and intervals and sometimes still comes back over the launcher, but the fast switch between launcher and clock is great. Drawing the widgets also does not yet work correctly.
    I think the next question is how to check during development that nothing is left over ;)

    Edit: Got it mostly working now. There seems to be some state left with regard to the widgets which causes them not to be rendered after switching back and forth with them visible. The rest seems to be working pretty well.
    https://github.com/halemmerich/BangleAppĀ­s/tree/unload

  • in Bangle.js
    Avatar for halemmerich

    That is quite possible, both buttons went while the watch wasn't on my wrist. The first defective button was on a watch that was mainly on my wrist, but it was an early bangle. The v2.1 defective button was on a watch used practically exclusively off my wrist for developing and testing, so a lot of handling it in different ways.

  • in Bangle.js
    Avatar for halemmerich

    I got the screen removed and the button was about 2/10 of a mm out of position. Moved it back and for now its working again. Not exactly as clicky as before, but usable.

  • in Bangle.js
    Avatar for halemmerich

    My second button (v2.1) just went, this time I could actually feel/hear movement inside the watch and the "springyness" of the button was gone. Will try to fix it myself this time. How hard can it be

    ;)

  • in Bangle.js
    Avatar for halemmerich

    I just did not test it because I don't have a JS1, it will probably work just fine :)

  • in Bangle.js
    Avatar for halemmerich

    I have done some experimenting with numbers read from a file and found the following two problems:

    require("Storage").write("test","teststrĀ­ing");
    require("Storage").read("test");
    let newString = require("Storage").read("test");
    newString += "other";
    // "other" is missing from string
    print(newString);
    
    require("Storage").write("test","123");
    require("Storage").read("test");
    let newString = require("Storage").read("test");
    newString += 123;
    // internal error, same if appending string to number read from file
    print(newString);
    

    I imagine both of these are caused by the file based strings mapped directly to the file instead of living in RAM as the other strings do.
    This behaviour can be worked around by prepending an empty string when reading:

    newString = "" + require("Storage").read("test");
    

    Does this mean, that the whole resulting string is in RAM? Not that bad for my usecase, since I am reading a few bytes at a time from a bigger file, but could be relevant when reading whole files.

Actions