Search results for:

Mine came off within days. Aggressive sweat is the likely cause in my case. Masking tape is doing the job for now but I'm considering superglue or something for long term.

I had no idea adding a date was a possibility. Not sure how I missed it, may have been the visual offset from "msg" that put it in the day of week section in my head. Possibly also carryover expectations from when I last looked the alarm app.

I have to dig into it but it should cover my use cases.

The only concern would be whether applications that don't handle dates may be confused.

As it stands the scheduling library is highly alarm focused.

Would it make sense to extend it to encompass the scheduling of events with absolute timestamps?

Potential benefits:

1. Countdown timers would gain the ability to schedule more than 24 hours out and accurate negative time.
   
2. Persistent stopwatches.
   
3. Syncing of calendar events.
   
4. Place for apps to push events such as sunrise and sunset.
   

Well, looks like most of the issue is me my dry fingers plus some touch screen imprecision. Tapping in place can produce a minor, but distinct spread which is enough to miss repeatedly given the size of the buttons.

That said, occasionally the touch event does not fire, in which case the prompt tends to not respond. Very rarely the prompt works but the touch event does not or the crosshair is drawn over a button with no response from the prompt.

EDIT: notably I have not had any trouble reliably hitting, e.g., buttons in the calculator app. I don't know if there's a UX difference with full screen applications prompting me to be more precise or something else.

I should have noticed that, sorry.

Good thing I do actually like fish
.

It happens very consistently at the very least with alarm app timer prompts and prompts triggered from the web IDE.

Video of uploading the prompt example code and having to settle for two fish: https://youtu.be/O4mDtftum5U

Are you actually having issues and you think that might be the cause?

Not that I'm aware of. I intend to make timer app that can run in the background so I was trying to understand understand what exactly the alarm app does and why it does.

As noted, I think alarm.js is only called when an alarm is due, and it is called with load(...) so everything else is removed at that point and it's just the boot.js code that is run.

Does that mean that the clearInterval effectively only applies until alarm.js is done? That certainly would make it very unlikely to impact pending timeouts... I may have been more confused about how often boot actually runs in that case.

Is there some distinction between boot.js and boot0.js that could lead to another load of alarm.js? Or is there some some special handling of all alarm.js files as hinted in the BangleApps Readme (although I couldn't really find any more on that) that may affect it?

I may be overthinking things...

Do you mean you get the buzz immediately the first time?

Most of the time at least.

Are you on latest firmware, and have you done Storage compact recently?

Yes and yes.

It might just be something is happening that is taking a long time to complete

Possibly. However everything else has been responsive while prompts are reliably problematic, so at the very least they appear to be affected more.

on('tap') requires you to practically stab the screen to get it to work.

It appears to me that 'tap' is based on the physical movement of the watch. If that's the case Stabbing the screen is just a roundabout way to tap the front.

Would an immediate run not still pose problems for something earlier in the boot process?

I've been studying the alarm app and can not figure out how alarm.js can safely call clearInterval without affecting everything else that may be using timers or intervals. Is there something about the bangle architecture I'm missing that limits the impact of clearInterval?

I'm having intermittent unresponsive prompt behavior regardless of source (Messages, Alarms, custom prompts triggered from the IDE). The rightmost option is usually the worst and it can take several seconds of screen poking to finally trigger it. There is usually a buzz, which presumably indicates that the touch was registered.

The touchscreen seems to work perfectly fine with, for example, the touch timer app.

Any help or tips would be appreciated.