Probably due to 1,5° gap to distinguish events.

• Color | Tone | Background

• contrast option to show activity in higher contrast

Dev

• Tone: Light, Dark, Vivid, White background, Color background

• Color: add array to get the second dolor

• Date/activity color by tone: lighter purple/red on vivid

• Icons color alternatives or font

• Calendar colors by [background][mainColor]

Hi,

There is a problem when the day of week is displayed on Spanish, at least on forerunner 735xt (7.20)
It is: "Mié 3" is displayed as "Mi□ 3".
Maybe a possible easy solution is "Mie 3"

BR

Hello,

Currently the watch faces support non-pro Fenix 7 and Epix models, and the Fenix 7 Pro variants (all sizes), according to Connect IQ, and the project's source code.

However, the watch faces are not available for the Epix Pro variants. Is there a particular reason why these models cannot be supported?

Google blocks Garmin browser and none of them is willing to fix it.

The only workaround we found is making user to open oauth in his mobile browser and paste the auth code back. Dirty but works. Or we might be able to use OAuth for devices

OAuth for devices can do the trick https://developers.google.com/identity/protocols/OAuth2ForDevices

1. show link + code on watch

2. prompt with auth page that will direct him to the link in an easier way

3. he logs-in there

Background data is limited. Now it reliably loads just first 7 events from 8 events per calendar. The per calendar limit is tougher because the response json has lots of the data.

Either the background process or or background.exit method crashes when having less then then ~4800B of memory with ~760B data and ~420B auth-code.

Observed potential memory limits

• 8 full events per calendar / 8 with only dates: Out of Memory

• 14 total events with first 4 with full data: Watchdog Tripping

• battery/memory consumption of additional WebRequest is yet to be found

Experiments:

• 9 events will be passed by clearing names/locations of events except for the first 4 events or with adding:

  • it should pass first events across he calendar, not first events just from the first calendars loaded

  • double events would be passed by parsing date strings (25B) to Time.Moment.value (4B)

    • the parseISODate runs out of memory elsewhere, but converting just to Gregorian.Moment and solving a time-zone in bulk works.

  • 14 events with 10 events per calendar would be passed parsing just time (5B) like 18:30 or 1830 if we load only events within 24h and resolve boundaries given by event start/end difference

  • 14 events with 14 events per calendar would be passed if we request only start/end first and then summary/location only for first 4 events

  • over 14 would be passed by passing date as number instead of string, but crashes on Watchdog Tripping, so refactoring would be needed

Further savings?

• WebRequests eats the memory and takes time. What if we load the calendar ids instead of indexes and save both requests and memory by loading directly the events data without the need to load the calendar id first?

• refresh the idea with the paged calendars but making sure it does not run out of memory?

• aren't nested cycles better from the memory perspective than the recursion?

• read only start dates on the first request and then only load number of events that will stay within the limit

Ensure first events across calendars

• multidimensional array instead of calendar indexes would allow picking the first events across the calendar while more efficient insert-sort in LateApp as well

Beware the number of events passed can be decreased by the total memory available to the watch front-end

Any other ideas how to increase how many events are passed reliably and ensure those are the first events across the calendars, not just from the first ones.

7 events from 8 events from calendar is maximum to load now on Fenix6xPRO

watch has 29k memory, while background starts with 12k and sucessfully ends with having at least 4800

FR645m/FR245m/Vivoactive3m/Vivoactive4/4s have more free background memory

• It doesn't apply to non-m versions or another non-music devices like Fenix6xPRO.

• It loads up to 14 events, but then crashes on Watchdog Tripped Error instead

• decide strategy, ensure robustness and test edge-cases

Alternative might be feature: Experiment with companion app data loading

Memory

• Fonts (finally 11k saved: now 53k with one event)

  • ✅-500: fontMinutes shared with fontSmall

  • ✅-6000?: remove some i18n glyphs from fontSmall

  • ✅global vars

• ✅3-4/9 of 333B icons used: bitmaps2fonts (when all icons used) (9 icons: 3000 B, font 1700B)

• enum instead of dictionary

• not saving calendar_colors

• array to be checked by item array length instead of dictionary

• merge sort instead of bubbles

https://forums.garmin.com/developer/connect-iq/f/discussion/6000/preserving-memory-in-monkey-c

Battery

• prevent repetitive rendering except for metrics

  • minute changed => redraw: arc, metric, now, event time

  • data changed => redraw all

  • metric changed => redraw metric

• calendar dynamic scheduling

  • ✓ Turn data loading off when no BT

  • Dynamic data loading frequency:

    • ✓ loading quickly after layout,

    • ✓ then in lower frequency.

    • investigate: how quickly to load after error

  • ? Stop loading after auth error and warn it's not loading.

• precomputation:

  • events and markers

  • positions like notification

• jump tables to choose activity <=3 | <= 1 <=5 | ==0 ==4

Stats

• no redraw => 0-1 ms

• just activity => 1-2 ms

• calendar without events => 2-3 ms

• full calendar => 4-5 ms

Characters cut

• Aug is cut at g or p
• Čer is cut at Č

Dev

• Split numbers and date fonts
• Center numbers font
• variations for https://myneur.productboard.com/release-board/226-planning/features/368396 as followup

@myneur as you mainly worked on this, how difficult would it be to add this support? Authorizing with multiple accounts would be perfect.

Background data loading from the watch has many limits including the complex authentication. Also we would need to add support for multiple calendar providers like Apple and Outlook.

Wouldn't a simple Android+iOS companion app with just as a setting which calendars to load in which colors work better?

Isn't it better even from the battery perspective if it could push data only on changes instead of watch polling API constantly?

show time to event end instead of next event if the next event is more than 30 min after the end of the current one or there is no next event at all

This will be fixed when we switch to OAuth for devices

Hide client secret not to be passed as GET and trackable

Hash code or primary calendar to count unique users

Garmin Mobile Connect didn't show the login page at all regardless the app was reinstalled.

Help with picking calendars and writing code

1. open a configuration page in mobile browser after successful login

2. choose calendars to show

3. pending request to get calendar_ids

Alternative might be feature: Experiment with companion app data loading

Hi. I'm wondering if it would be possible to add a setting to adjust the outer 24 hour circle 180 degrees so that noon is on top and midnight is on the bottom. For me (and I guess many others) having it this way feels more familiar.

Great app!

Background process passes data by pages within the ~1k data limit.

Show simple weather forecast from yr.on API.

• rain in blue

• sun in yellow

• snow white

• darker colors during night

Delivery

trim the event text not to overlap the screen

Some devices are unable to log-in because of a Garmin bug reported here:

forums.garmin.com/.../makewebrequest-bad-request-on-some-devices

Please vote for it so Garmin fixes it soonish rather than laterish.

The domain will solve it.

currently Google business calendars are not shown in the oauth list to pick from

...when user made mistake or changed his mind. It can be as simple as a bool property to ask for new calendars.

• graceful degradation on no-data low-memory devices

• conditional data loading code and settings

• default settings