Best Practice for Loading Strings, Fonts, and Settings in Watch Face with Background and Typecheck

The type checker pretty much tells you what to do. It's never to change your logic. It's always to change the declaration or in certain cases you might need an explicit type cast (most of these cases are due to it being not smart enough, so I consider it a type checker bug)

So in 95% of the cases the only thing you need to do is to add either at the declaration or in some expression "as Type"

If you change your logic because of type check warnings, then you probably should rather turn it off - though as a new Monkey C developer, I think you could benefit from having it enabled, but that needs you to go WITH it and not to try to WORK AROUND it.

flocsy🤠 said:

It's never to change your logic

I disagree. For example, sometimes the type checker will tell you that you are accessing a field that’s typed to be T or null, but ignoring the fact that it might be null. If such a field is an API field, then you literally can’t change the type declaration, and you probably shouldn’t cast the value. [I’m not referring to the kind of situation where loadResource returns a Resource, but you know for sure that you can cast it to FontResource bc you specified a font resource id as an argument]

Sometimes the correct solution to a type checker error is to change your logic to handle the case where a field is a type (such as Null) that you weren’t expecting.

[1/x]

e.g. If you build the following code on SDK 7.1.0 with type check level 2 or higher, you will get a warning or error about calling substring on observationLocationName, because observationLocationName is typed to be String or Null, and substring is a method on String [obviously the Null type has no methods].

[Yes, I purposely chose an older SDK because observationLocationName is now deprecated, so you actually shouldn’t be using it at all. But since the failure to check observationLocationName for a null value is a real problem that affects real apps and it could have been caught with type checking, I’m using it as an example.]

var currentConditions = Weather.getCurrentConditions();
if (currentConditions != null) {
  var abbreviatedLocationName = currentConditions.observationLocationName.substring(0, 10); // should produce error to the effect of “symbol ‘substring’ not found on Null” or something like that

  // yes, in this case it doesn’t “look” like a type check error, but it’s actually the type checker that detects whether a symbol exists on a given type
  // I could’ve contrived a different example which would’ve produced a type mismatch error to the effect that you can’t pass String or Null into a function that expects only string
  // …
  // draw locationName on screen
}

[2/x]

Ofc a null check (as in the example above) is just one specific example of a type guard.

And again, I would argue that a type cast should always be the option of last resort, only to be used when:

- the API gives you no choice (e.g. when calling Application.Storage.setValue() on the data returned by makeImageRequest on a CIQ 4+ device). This is usually due to a bug or limitation in the API / type system.

- you are *absolutely* sure you know what you are doing. (The problem is that, unlike TypeScript, Monkey C will make no attempt to verify whether your type cast makes sense. TypeScript will warn you if you try to cast between unrelated types, meaning that it tries to prevent unsafe casts. Monkey C has no such protection against unsafe casts)

Ok, so this is an example where the type checker found an actual bug in the code, and fixing it indeed needs changing the logic (need to check if observationLocationName is null), but that's the way the code should've been written even without type checker.

But when you declare a variable as: var foo; and the type checker reminds you to state it's type, and you change the code to: var foo as Number; then this is not changing the logic.