messagegui: don't write messages to flash quite as often

[rigrig]

• Fast load messages without writing them to flash
  it checks if (Bangle.load === load) // write to flash anyway to prevent breakage on old firmwares
  Still writes to flash if we decide not to load the app
• In-app: we already saved MESSAGES in E.on("kill", so just remove all earlier calls to saveMessages()

[gfwilliams]

Thanks! I hadn't really twigged that we don't even load the messages JSON from Storage any more unless it's a 't:"modify"' message - so this works really nicely.

Is this all tested and good to go?

[rigrig]

I faked a few messages through the IDE with GB(), everything seemed to work as expected, and they showed up in messages.json (only) after I closed the app.

[gfwilliams]

Ok, great - thanks!

[digitalcircuit]

After upgrading from the stable Messages app to this version, most (all?) messages forwarded from the Bangle.js Gadgetbridge app to my Bangle.js 2 result in circlesclock being replaced by Message UI app opening up, only to say "No messages" and close. I'm able to get messages working again by downgrading Messages (removing the split-out widget and UI apps) and downgrading the Android integration app.

If I should file a new issue on the forum, if there's any sort of debugging that would help, etc, let me know!

Apps: antonclk, widbat, widbt, agenda, mylocation, agpsdata, gpsautotime, locale, widalarmeta, quicklaunch, multitimer, boot, launch, health, setting, about, widlock, messageicons, sched, alarm, circlesclock, weather, kbswipe, clkinfosunrise, owmweather, messages, android
(This is after downgrading - there were separate message UI and message widget apps before.)

---

EDIT: I'm running into unrelated issues as well - I've seen both FIFO_FULL and MEMORY_BUSY even with the downgraded messages app. I'll need to narrow down what upgrades went wrong for those problems.

However, downgrading the Messages and Android app fixed notifications even with those issues.

[gfwilliams]

Thanks for letting us know!

I'm just looking again at this code and it seems that while it'll work with a 'fast load' capable clock, if the clock can't fast load then it would fail. I believe I have now fixed this if you update messages to 0.59

(I have noticed occasionally seeing FIFO_FULL, but that may be unrelated as it still happens even with the downgraded messaging apps.)

I think that's probably unrelated - it happens when Gadgetbridge sends data to the watch too fast for it to be processed, and in particular circlesclock is very bad as it can take over 1.5 seconds to redraw itself sometimes - see #2251 (comment)

[digitalcircuit]

I've upgraded to 0.59 and it works now while using circlesclock, thank you!

I think that's probably unrelated - it happens when Gadgetbridge sends data to the watch too fast for it to be processed, and in particular circlesclock is very bad as it can take over 1.5 seconds to redraw itself sometimes - see #2251 (comment)

That makes sense.

It seems to be an interaction with both circlesclock and OWM Weather, since if I disable both apps I don't run into the issue. With circlesclock active but OWM disabled, the App Loader sometimes fails to list installed apps, and with antonclock active and OWM enabled, it only fails if there's a recent weather fetch (despite having refresh at default of 3h). With both active/enabled, it's very rare to get the app loader to work.

At this point I should probably file a new thread on the forum, an issue here, or whatever is preferred.

EDIT: I do want to emphasize that I appreciate all of the work the core contributors and others have put into this project! I realize I happened to pick some troublesome apps/clocks, but I'm still very happy with this and appreciate the effort towards an open, community smart watch.

[gfwilliams]

Maybe a forum thread would be better - maybe you can find the OWM weather developer and mention them (or do it on GitHub if you can't find the maintainer there).

There is a PR for flow control in Gadgetbridge, but it hasn't been merged yet, so this will go away at that point. So it some ways you could consider the FIFO_FULL error fixed.

... but OWM weather might be making matters worse by requesting a whole bunch of data that it doesn't actually need. It's possible that by changing the HTTP request slightly it could get just the data it needs and not end up transferring a lot of stuff to the Bangle which causes the error