weather: Add function for converting to units

[FintasticMan]

Handles rounding correctly.

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	374576B	48B
data	948B	0B
bss	63504B	16B

[minacode]

You could use structs of one int to make the types really safe.

[JF002]

I'm ok with the current state. I however thought about another option.

SimpleWeatherService would define a Temperature type : PineTime::Controllers::SimpleWeatherService::Temperature. It's the internal representation of a temperature in the SompleWeatherService expressed in "°C * 100"

struct Temperature {
  int16_t temperature;
}

Somewhere under DisplayApp, we would define another Temperature type : Pinetime::Applications::Temperature. It represent the temperature for the UI side of InfiniTime as an std::variant (TODO : check that the overhead of std::variant is negligible)

struct TemperatureCelsius {
  int16_t temperature;
}

struct TemperatureFahrenheit {
  int16_t temperature;
}

using Temperature = std::variant<TemperatureCelsius, TemperatureFahrenheit temperature

Then, also under DisplayApp, we define a function that converts from SimpleWeatherService Temperature to "display" temperature :

Pinetime::Applications::Temperature Convert(PineTime::Controllers::SimpleWeatherService::Temperature, Controllers::Settings::WeatherFormat format);

This way, all the "temperature" types are strongly typed and it's impossible to implicitly convert from one to another. Also SimpleWeatherService does not have any code related to the UI anymore.

[FintasticMan]

@JF002 I've just refactored this a bit, what do you think? I wasn't able to use std::variant, as it is very strict about knowing which variant to use at compile-time. That meant that we needed 2 completely separate code paths for Celsius and Fahrenheit.

[FintasticMan]

I'm not a big fan of having the default value be 0 here, but otherwise the compiler complains about there being no default value for the array of Days in the Forecast.

[minacode]

I think it would be conceptually better (maybe not memory-wise) to make the days array of type:
std::array<std::optional<Day>, nbOfDays>. Then you would not need to construct Days without values.

[L3br4nd]

Would defining Temperature in Kelvin internally and converting to DisplayTemperature in °C or °F depending on the user setting for displaying be helpful?
Sorry, I'm not into object based programming that much...

[minacode]

I don't think that is the problem here. The internal representation is never shown directly and can therefore be whatever. The problem is, that right now we need a temperature value in a place where no value should be.

[FintasticMan]

I think std::optional does make sense, I'm going to see how implementing it like that looks.

[FintasticMan]

I think this works quite well, what do you think?

[minacode]

I like the current approach with the raw value and the two representations! :)

[FintasticMan]

It should be correct to use nbDays rather than MaxNbForecastDays here, but we should test it before merging.

[JF002]

LGTM!