Simple Example WF that shows a bunch of things

I put together an example watch faces that demonstrates a whole bunch of things, all in one place.

Here's how it looks in the sim for the Venu3

Starting at the top, the date is shown using drawRadialText() if scaleable fonts are available on the watch. If not. it uses a standard font with drawText()

The next line is the result of a simple background service. It just returns a string with the time the background ran

Then the time. On devices with onPartialUpdate() (MIP devices) seconds update all the time. On AMOLED devices, when in low power mode, the time moves around to prevent burnin. On a real device, the screen blanks on AMOLED screens if AOD is off

The Heartrate is displayed in one of two ways. On devices with complications, it subscribes to COMPLICATION_TYPE_HEART_RATE, and if the device also has touch, pressing on it opens the heart rate glance. On devices that don't have complications, it gets the HR from Activity.Info

The last line changes based on if the device is in wheelchair mode (Venu3 and Vivoactive5 right now). "P:" indicates wheelchair mode and shows pushes. otherwise "S:" for steps.

It has app-settings for a few colors, and on-device settings for a leading 0 for hours.

Here's a zip of the project:

ComplexWF.zip

Top Replies

FlowState 4 days ago in reply to jim_m_58 +1

jim_m_58 said:
Monkey.jungle turns type checking off, so not a problem.

Well it would, if that line wasn't commented out.

Of course, even the monkey c extension gives you a warning that turning off…

All Replies

FlyFrosty 5 days ago in reply to TheHuff

You need to update it to the new(er) set-ups. For example...

function getInitialView() as [Views] or [Views, InputDelegates] {

function getSettingsView() {

var setView=new ComplexWFSettingsMenu();

return [setView,new ComplexWFSettingsMenuDelegate(setView)];

flocsy🤠 5 days ago

An example of the disagvantages of attaching a zip file instead of posting to git...

jim_m_58 4 days ago in reply to flocsy🤠

Monkey.jungle turns type checking off, so not a problem. It would be the same with git

FlowState 4 days ago in reply to jim_m_58

jim_m_58 said:
Monkey.jungle turns type checking off, so not a problem.

Well it would, if that line wasn't commented out.

Of course, even the monkey c extension gives you a warning that turning off type checking will disable several useful language features :/. (I mean useful to others, I know you don't need those features.)

jim_m_58 said:
It would be the same with git

I'll take "missing the point" for $200, Alex. I think flocsy's point is that others could collaborate with you and fix type checking errors, for example, if you were using github, not that github would magically change the way your code builds. Or that you yourself could easily update your project (with a nice history of changes), without having to reattach the zip file manually.

For all those decades when you presumably worked in teams at companies, did you just zip up changes to your source code and email them to your colleagues? Oh, let me guess, everyone just edited the same source code project on a shared network drive with no version control, just regular backups. I bet there were cases where one dev accidentally clobbered someone else's changes because everyone worked on the same files.

Nobody can or should force you to use github, but at the same time, you are not going to convince anyone that there's no benefit to using github at all. (Github has 100 million developers, and the CIQ forum has less than 10 regular posters.) And in the case that you don't want to share stuff publicly (and you don't trust github with your private code), git is still very useful. I host a private git server for my personal projects.

jim_m_58 4 days ago in reply to FlowState

Do whatever you want. Same for me. I don't use git for any of my code.

TheHuff 4 days ago in reply to FlyFrosty

@FlyFrosty Thank you so much. Working now.

Can you please tell me why the function definition for getInitialView defines its return types but getSettingsView does not?

(I am new to Monkey C)

FlowState 3 days ago in reply to TheHuff

TheHuff said:
Can you please tell me why the function definition for getInitialView defines its return types but getSettingsView does not?

Technically, neither function needs to be explicitly typed as each one overrides a function with the same name in the base class (AppBase), so the compiler already knows the type (it's the same as the overridden function's type). As a matter of fact:

- if you accidentally defined either function with incorrect arg/return types (which don't match the overridden function), then the compiler would raise an error

- if you hover over getSettingsView() in VS Code, you can see actual args/return type for that function (which demonstrates that the compiler knows without the types being explicitly specified)

Personally, in the interests of consistency and readability, I would probably explicitly type all such overrides, but there's nothing wrong with the current code.

Additionally, for the default type check level, functions and variables are not required to be explicitly typed anyway, although lack of type information becomes a warning or error at higher levels. This doesn't apply to getSettingsView() though, since the compiler already know its type.

(I will say that there would be one advantage to *not* explicitly typing getInitialView(): the current return type for this function uses syntax that doesn't work with older SDKs like 6.4.2, so if for some reason you need to build with both older SDKs and newer SDKs without modifying your code every time you switch, you would have to leave getInitialView's return type unspecified. In general we should all be building with the latest SDK tho.)