Avatar for user141569

user141569

Member since Mar 2022 • Last active Aug 2022
  • 3 conversations
  • 18 comments

Most recent activity

  • in Bangle.js
    Avatar for user141569

    In a way that's probably the best thing that can happen - the battery gets run down more quickly, the Bangle gets warmer internally and dries itself out quicker :)

    Is the heat from the CPU and backlight really that significant?

    But it's definitely worth giving it time - even if the Bangle comes back to life it doesn't mean it's 100% dry inside, so long term it's better to give it a good long time to dry out.

    I guess I shall heat lamp it more. It's just hard to be without my watch for that long.

    I'll reply in http://forum.espruino.com/conversations/­378470/#comment16640058 in a second, but if you do end up having to replace the Bangle I'm very happy to offer a discount. I don't think I should lose money replacing a water-damaged Bangle when the docs say no swimming, but I also don't want to profit from your misfortune :)

    Thanks for the offer. That sounds pretty fair to me. I'm going to keep my Bangle for now, but if it dies I'll let you know.

  • in Bangle.js
    Avatar for user141569

    So that's why I sometimes see (function(){ /* stuff */ })(); being done! That's a far better idea than using global variables with naming conventions. I'm going to use function scopes instead. Obviously with nice clean names because I can get away with them now.

  • in Bangle.js
    Avatar for user141569

    Thanks for pointing out bthrm. (It's not a thing I personally use, so I never thought to check it out.) It does seem to have the same goal (modifying Bangle.on), but it goes about it in a different way. bthrm uses Bangle.origOn, and my own app uses AUTOSWP2CLK.on. I think both approaches have some advantages and disadvantages. With bthrm's approach, we don't create confusion about which object is getting an event listener and we don't need to use .call to force the event listener to be assigned to something it wouldn't normally be assigned to. (We clearly do have that issue with my approach.) However, my approach is less likely to create naming conflicts with other boot code, because it seems far more likely to me that another app will want to create an object called Bangle.origOn than an object called AUTOSWP2CLK.

    I went for a combination of the two approaches: create more children of Bangle rather than a top level object, but call them something like AUTOSWP2CLKORIG rather than just orig. This works as expected.

    Is there a proper convention for names of objects created by boot code, or am I too paranoid about naming conflicts? I feel like they should have the name of the app somewhere in there to allow different pieces of boot code to distinguish variables from each other, and also have some way to distinguish boot code variables from the main app's variables. Like maybe have boot code objects be named BOOT, and have the main apps avoid creating objects with names starting with BOOT_ which I don't think they'd really have any reason to anyways?

    TLDR: Thanks, that fixed it.

  • in Bangle.js
    Avatar for user141569

    I'm also glad mine is OK. Well, the battery did run down quickly while the watch was bootlooping, but that was probably because of the backlight being on and the CPU being active for several hours straight. Probably about 80% when it started and 30% when it ended a few hours later. Battery life has been normal ever since. So I'm guessing we have no short circuits anywhere.

    And don't worry, even with the slight delay, the customer service is probably still the best I've ever experienced.

  • in Bangle.js
    Avatar for user141569

    Your theory about the heat wave in Europe makes a lot of sense. Far more than my software update idea. I'm not in Europe (not sure what % of people are vs around the worlf), but I guess coincidentally the heat wave there happened during a family vacation to a lake, where the temptation to swim is strong.

    My watch was bought from the Espruino shop (not Kickstarter) and appears to have the membrane. I think I blame the button.

  • in Bangle.js
    Avatar for user141569

    There is an app (swp2clk) which allows the user to swipe back to the clock. To avoid interfering with apps that use the swipe gesture for their own purposes, you have to use the settings menu to configure which apps get the treatment. I like swiping back to the clock, but I find this configuration to be annoying (and don't like that swp2clk writes the app name to storage every time an app is loaded), so I'm trying to make a similar app that does this automatically: apps that do not register any swipe handlers will have swiping go back to the clock, and apps that do register swipe handlers will just have their swipe handlers run as usual.

    To do this, I'm trying to override Bangle.on(). The custom Bangle.on will pass all calls with an event type other than 'swipe' to the native Bangle.on (which I will store somewhere else) to avoid unnecessary complexity, but when the event type is 'swipe' the supplied function will be stored in an array. The native (non-overridden) Bangle.on will be called with an event type of 'swipe' and a function that will either call load() if there are no functions in the array, or call each function in the array (and not call load) if there's at least one. This should result in things appearing mostly unchanged, except for the illusion of a "default" swipe handler that goes back to the clock.

    I have developed the following code (autoswp2clk.boot.js) to try to achieve this:

    const AUTOSWP2CLK = {
      on: Bangle.on,                                  // Original, unmodified Bangle.on()
      removeListener: Bangle.removeListener,          // Original Bangle.removeListener()
      removeAllListeners: Bangle.removeAllListeners,  // Original Bangle.removeAllListeners()
      swipeHandlers: []                               // Array of swipe handlers
    };
    
    Bangle.on = (eventName, func) => {
      if (eventName == 'swipe') {
        AUTOSWP2CLK.swipeHandlers.push(func);
      } else {
        AUTOSWP2CLK.on(eventName, func);
      }
    };
    
    Bangle.removeListener = (eventName, func) => {
      if (eventName == 'swipe') {
        AUTOSWP2CLK.swipeHandlers.splice(AUTOSWP­2CLK.swipeHandlers.indexOf(func), 1);
      } else {
        AUTOSWP2CLK.removeListener(eventName, func);
      }
    };
    
    Bangle.removeAllListeners = (eventName) => {
      if (eventName == 'swipe') {
        AUTOSWP2CLK.swipeHandlers = [];
      } else {
        AUTOSWP2CLK.removeAllListeners(eventName­);
      }
    };
    
    // Using the old Bangle.on rather than the new one
    AUTOSWP2CLK.on('swipe', (dirLR, dirUD) => {
      if (AUTOSWP2CLK.swipeHandlers.length == 0) {
        load();
      } else {
        for (let func of AUTOSWP2CLK.swipeHandlers) {
          func(dirLR, dirUD);
        }
      }
    });
    

    (I also have a removeListener and removeAllListeners for compatibility, but have not tested them yet.)

    However, what actually happens is that this app breaks basically everything, because Bangle.on() no longer registers event listeners. If I manually call AUTOSWP2CLK.on() which should be the unmodified Bangle.on(), it also does nothing, implying that this has broken it. Is what I'm trying to do possible and I'm just doing it wrong, or is this not possible?

  • in Bangle.js
    Avatar for user141569

    Mine actually dried out on its own over the course of a few hours while I was still wearing it. But just in case I ran down the battery and left it directly under an incandescent light for a few hours. It doesn't seem to be damaged, but I'm now going to take it off before going into the water again.

  • in Bangle.js
    Avatar for user141569

    Yeah, same here. Mine started bootlooping seconds after being pulled out of the water. It was also in the water a few times before and it was fine. I guess no swimming really means absolutely no swimming of any kind, not even light swimming.

  • in Bangle.js
    Avatar for user141569

    Was your Bangle in water recently? It seems like me and someone else have an issue where the MCU thinks the button is constantly pressed because of water intrusion.

Actions