agenda: displaying calendar colour and name

[glemco]

I already submitted a pull request on gadgetbridge for this to be supported, it might take a little time for users to see this actually working.

[gfwilliams]

Great, thanks! Yes, just to check - did the PR get merged? If so I'll have to do a new Gadgetbridge release for the Play Store soon.

[glemco]

Well, it has been approved but not merged yet, I'm not sure how long will that take.
You can follow any updates here https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2836 (or I can comment on this thread once merged).
The same pull request has the fix for #2086

[glemco]

Merged now

[gfwilliams]

Great!

[gfwilliams]

Hi! Is this still working for you? I've had a report about Gadgetbridge not syncing the calendar and after trying it's not working for me either.

It seems that if you enable Calendar Sync in Gadgetbridge and click set time in Debug you can kick off a force_calendar_sync_start, and Gadgetbridge will remove any calendar events that aren't there - but it won't add any new calendar events.

Any thoughts? Is there some trick we're missing?

[glemco]

Hi, I have noticed sometimes some events are out of sync (e.g. it takes time to delete old events).
The thing with force_calendar_sync is that rather than adding events, it's checking the missing ones and deleting them from the GB database (so that it doesn't think we have it on the watch).
Later it should trigger a sync with the android calendar and the missing events should be synchronized (likewise old events should be deleted). I'm not really sure why but the android calendar is checked only after a reconnection. Now I'm not really familiar with Intents so this is what I'm doing:

https://github.com/gfwilliams/Gadgetbridge/blob/30ff3673e1ce32cec31019a813560ad5f8945926/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/devices/banglejs/BangleJSDeviceSupport.java#L768

I'm not sure what exactly is kicking the CalendarReceiver on reconnection, but it would be ideal to kick in immediately.
Another thing I'm considering is to send a force_calendar_sync on every new connection (rather than set time, as it isn't as frequent as I was expecting). In the worst case it would synchronize all events at every reconnection, but in the best case (hopefully much more likely) it wouldn't really fetch anything.
Again, this modification wouldn't really be effective in the current situation as the force_calendar_sync would wait for yet another reconnection for the events to by synchronized.

TL;DR
At the moment, for the force_calendar_sync to work you need to disconnect and reconnect GB, if you have any idea how to run that CalendarReceiver properly, we could make this process much better.

[gfwilliams]

Thanks! Yes, I saw the CalendarReceiver kicking going on. Just in my case everything apart from that seemed to work.

Actually I just started stepping through, and it turns out that for some reason Gadgetbridge hadn't been given permissions to my calendar! I checked and Gadgetbridge definitely requests access but my phone (Redmi) has done this kind of thing before like ignoring Location:Always requests.

Did you have to do anything, or did it 'just work' for you?

Actually there's no reason that Bangle.js couldn't kick off force_calendar_sync on reconnect. After all, it would save one to-and-fro of data. Do you think that makes sense?

But... as you say, calling CalendarReceiver definitely didn't work either. I've just put a PR in for this at https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2981

[glemco]

Well, I haven't used MIUI in a long while, but I bet there can be problems! At most I had to set it manually from the settings (I don't remember exactly if the request was prompted the first time, but most likely yes), so no real special step (but I'm on a LineageOS based). If you did something for your Redmi, we could add the steps somewhere (wiki? agenda's README?).

I agree with the bangle asking directly, it shouldn't break anything (as far as I can see, not even if we aren't using the calendar) and with your fix it looks much neater!

[gfwilliams]

Ok, great! I'll push a change to request the calendar sync.

And yes, I've updated https://github.com/espruino/EspruinoDocs/blob/master/info/Gadgetbridge.md so it'll go live on http://www.espruino.com/Gadgetbridge next time I update the website.

One thing I have noticed is Gadgetbridge can cause a FIFO_FULL error when syncing calendar (that's mainly my fault for not having flow control in Gadgetbridge yet) but I noticed that the description of calendar events can be huge, especially when you have something like a video call. Maybe we should attempt to crop those to a sensible length?

[glemco]

Great, thanks!

Yeah, probably that would be the best, do you have any idea of a good number? Is there any strict limit we should respect or just bigger messages increase the probability?
I think this problem would be noticeable also for notifications bodies, is there any limit on those?

[gfwilliams]

Is there any strict limit we should respect or just bigger messages increase the probability?

It's just bigger messages. I guess maybe we think about what we can actually sensibly display? 200 chars?

Also, other things that might matter:

• Would we ever use "calName":"account_name_local/calendar_displayname_local" it's big in each one and I guess we could just drop that (or at minimum disable it if it's the default value).
• The color ends up being negative (I guess it's 0xFFbbggrr and the 0xFF makes it negative). We could just convert it to 16 bit in Gadgetbridge I guess?

[glemco]

Yeah looks like a fine value.

• We don't really use it at the moment, I actually never noticed as I'm not using the default calendar, if it's always the same value I guess we can safely hide it (something like /default, /other_cal_name, etc..). I can give it a try.
• I didn't change the initial representation, I can check for what can be smaller as represented as a string (although I don't think it can save much more than a couple of char), maybe a base64 of the binary representation (again cutting the crumbs)?

[gfwilliams]

Ok, great. I think probably for now let's just get rid of "calName"? The color seems like it's enough.

And yes, the color thing won't save many characters - it might just be a little tidier

[glemco]

Well, it's nice to give a little more context rather than just the colour if you have multiple calendars, but if you see it useless, let's get rid of it

[gfwilliams]

Well, not useless, but maybe not useful at the moment - and anything we can do to reduce the amount of data we send the better :)