The face of my Garmin watch
Followers of this blog know that I am a Garmin watch wearer, and that I have mentioned things to think about when installing ConnectIQ.
To get the most out of these devices, one might wish to create a custom watch face. I've done so. My preference is for a fairly clean analog watch, with a four digit text field at the lower part of the screen as an alternative representation of the time. In addition to time, I find it useful to have easy access to the day of month and the day of week and have thus placed those on the right. At the top is my timezone offset to UTC. All the space on the left side of the screen is used to display clocks of a few other time zones.
Above are two images illustrating how the watch face looks. The information about the current day moves around slightly, to avoid being covered by the hands. Most of the time the hands are solid white. After days of use, when most of the energy has been used up, the hands starts to act as battery meters; turning more and more red as the need to charge comes closer.
Development for Garmin watches is done in their Monkey C language. Those well acquainted with it might realize the API seemingly lacks support for drawing neatly looking bi-colored hands. There are methods for drawing lines, placing texts and the like, but I could not obtain satisfactory results using the available graphical directives. Direct bitmap manipulation was not added until API level 4.0.0. My device, the vivoactive3, only supports 3.1.0 for which one instead can loop over all angles in the small circle sectors surrounding the hands, drawing the hand in every iteration of the loop and abuse setClip() to get pixel level control over making it partly red. Clearly this is insanely heavy, and not how the clipping interface was intended to be used. However, it fits within the tiny computational allocation provided, gets the job done and renders a watch face pleasant for the eyes.
The four additional time zones are hard coded, and I admit having been lazy with them. As my simplistic algorithm does not care about the time of day, they are partially off by an hour on the four days of the year when the US or Australia changes in or out of daylight savings time, but they should be correct all other 361ΒΌ days.
Source code available? Yup, it's published as mazarine-watch for anyone curious enough. Beware, it's written to be just good enough and might be too rough to be appealing to look at.