WatchFace crashes when my phone's bluetooth is off and while I'm sleeping

But, where is possible to set temperature in F?, In the simulator is only in C and the max is 100, and in the documentation is in C as well.

jim_m_58 said:

And as far as handling the data like temperature, if what you see is a Number for a Float, if you do a proper conversion to F, the result will be a float.

Be that as it may:

- it’s still important for the types to be correct in the API/documentation, and for developers to know what the correct types are. you have literally participated in threads relating to bugs arising from the previously incorrect types

- you know that there are places in the world that use Celsius right? You make it sound like the case for Celsius is negligible for everyone just bc it is for you. (In fact, the US is one of a very few countries in the world that exclusively use Fahrenheit. Most countries use Celsius.)

However, I do agree that a watchface which is aimed at users all over the world (including the United States) should probably also support Fahrenheit as well as Celsius. But you can’t just optimize only for the Fahrenheit case, same as you can’t just assume the Celsius case.

jim_m_58 said:

And a simpler way to handle this is to just use

temperature.format("%0.1f"),

where you just show  it with 1 decimal point, so you don't need to do rounding in the integer part.  The decimal point is nice  - right now it's 109.9 so easy to see it's almost 110F!

Whether it’s simpler code or not, it’s not equivalent. As a matter of fact, it’s more complex for the user.

The choice to display 0 or 1 decimal places for temperature shouldn’t be based on how simple the code is, it should be based on considerations like what the user wants to see (or what the dev wants to show the user), how much space there is in the UI, etc.

As a counter-example, the weather app on my iphone shows 0 decimal places for temperature, same as the weather widget in Windows, and same as the google snippet from weather.com.

I’d bet that every weather service aimed at normal, non-technical people uses 0 decimal places for temperature.

My point was that the code as written was truncating and not rounding to the nearest integer. Given that the existing code was meant to display 0 decimal places, I think it makes more sense to go with a solution that still displays 0 decimal places, but with a better rounding strategy. (Unless the intent is to truncate / round towards 0, in which case it doesn’t need to change.)

I will also point out that using format("%0.1f") doesn’t really solve the original problem at all. It’s still truncating, but it’s just truncating to 1 decimal place. For example, if the underlying value is 109.99999999, I would expect that to be displayed as 110.0 after rounding, but format("%0.1f") will most likely display that as 109.9.

jim_m_58 said:

The decimal point is nice  - right now it's 109.9 so easy to see it's almost 110F!

You know what would be even easier for the user? Simply displaying “110”. Ask yourself why weather.com only shows integer temperatures.

Juan Domínguez said:

I'll double-check all my code to cover any missing null checks.

If you change your typecheck level to informative/2 or strict/3, the type checker will do this for you — assuming there are no bugs in the API types for values that you use. But if there are bugs in the API types, then the docs are almost certainly affected as well, which means it would be hard for you to locate missing null checks in those cases anyway (unless you already have code that crashes due to a missing null check.)

Juan Domínguez said:

However, I'm curious why my watch face is still crashing even though I have a try-catch block around the code. Could you shed some light on this behavior?

To clarify the other answer, try-catch is for (non-fatal) exceptions and only exceptions, not (fatal) errors. Not only will an exception show up in the console / error log with the text “Exception” (if it is not caught), the related function should also be documented to throw the given exception (which will have a corresponding Monkey C class that extends Toybox.Lang.Exception.)

Unfortunately, unlike Java (for example), Monkey C has a lot of fatal errors which can’t be caught. e.g. Java has a NullPointerException that can be caught, but the equivalent situation in Monkey C results in a fatal error.

More info:

https://developer.garmin.com/connect-iq/monkey-c/exceptions-and-errors/

In an app, use System.getDeviceSettings().temperatureUnits

in the sim, you control this with Settings>Units Display (statue is F)

It's often under Settings>System>Units on a watch itself.

What you see in currentConditions is C so you do a conversion to F if needed based on temperatureUnits.

ALL my non ciq weather devices show a decimal point with temperature, including the 3 different weather stations I've used over the years.

109.999999 should show as 109.9 in my opinion as it's not 110, and 110 could trigger something else.  For example, I get an alert from my weather station when it gets to 115 or above,  Not 114.999999

Hi FlowState and jim_m_58,

Thank you both for the detailed responses and suggestions. I appreciate the insights regarding temperature handling and null checks.

I most say I agree with FlowState, most of the countries use Celsius, and in fact I do use it, but yes I need to support both, and I didn't have it into account before this came out in this discussion.

FlowState said:

If you change your typecheck level to informative/2 or strict/3, the type checker will do this for you

About the type checks and rounding, I'll definitely revise my code to ensure correct null checks and better rounding strategies, but where can I define the typecheck level in VSCode?

jim_m_58 said:

To convert to F, this works.  with the 9.0 instead of just 9, it's doing the math with floats, resulting in a float

t=(t*9.0)/5+32;

Regarding this comment, I still have a question about temperature units. Is it correct that the watch always provides temperature in Celsius, even if the user is in the US? Do I need to manually convert the temperature to Fahrenheit based on the user's settings or I just should display the value that comes in the .temperature and that's it?

I appreciate your help in clarifying this cause I'm a bit confuse now.

Thanks again for your support!

What you explain makes sense and in part I think it's kinda cool to have the decimal point, however I have never seen or used the temperature with that level of accuracy, I have only used it in Celsius with whole numbers and seen F with whole numbers as well.

I thought that decimals in temperatures were for more advanced devices such as more precise measurements by scientists and such, but not for a normal user who has a Garmin watch and wants to see the temperature eventually without having to go to the mobile phone.

So, to be fair, I don't have a strong opinion here.

Yes, it's always C so if you just display that it will be C.  So you need to check the setting and convert to F yourself if needed.

But rounding is the wrong approach to me, even without a decimal point. if it's 109.99 display 109, as it's not 110...Maybe really close to 110, but not there yet.

Even my wall clocks that show indoor temperature have 1 decimal point....

To add another level of confusion, if you display something like rain or wind speed, you also want to convert to statue there if needed.

Ok always C, that's cristal clear now! I'll decide what to do in regards to the decimal point. 

jim_m_58 said:

To add another level of confusion, if you display something like rain or wind speed, you also want to convert to statue there if needed.

Yes, sure, I'll take that into account as well.

It was a very interesting discussion. Thanks again for your patience and willingness to help. I will cover the F scenario.

I let you know if I have any further questions.

/Juan