Feature/weather uv index

[sebastinto]

Summary

Adds optional UV index info to the weather command.

Changes

• Settings: Added "Include UV Index in Weather Report" toggle (defaults to disabled)
• Weather Command: UV index now displays conditionally based on user preference
• Internationalization: Added translations for all 5 supported languages

Screenshots

Testing

• Settings toggle persists
• Weather command respects the setting state
• UV index is formatted properly

[coderGtm]

Thanks for the PRs @sebastinto
I'll be reviewing it soon.

Also, is the UV index always available?

[Copilot]

Pull Request Overview

This PR adds optional UV index information to the weather command functionality. Users can now enable/disable UV index display through a new setting in the settings screen.

• Added a new toggle setting to control UV index display in weather reports
• Modified weather command to conditionally show UV index based on user preference
• Added translations for the new feature across all supported languages (English, Italian, Russian, Spanish, Ukrainian, Serbian)

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
app/src/main/res/values/strings.xml	Added English strings for UV index weather display and settings toggle
app/src/main/res/values-*/strings.xml	Added translations for UV index strings in Ukrainian, Serbian, Russian, Italian, and Spanish
app/src/main/res/layout/activity_settings.xml	Added UV index toggle switch to settings UI
app/src/main/java/com/coderGtm/yantra/commands/weather/Helper.kt	Added conditional UV index display logic in weather command
app/src/main/java/com/coderGtm/yantra/activities/SettingsActivity.kt	Added UV index preference handling and switch initialization

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[sebastinto]

Thanks for the PRs @sebastinto I'll be reviewing it soon.

Also, is the UV index always available?

My understanding is that by default it is but can be disabled / enabled:

By default we return all weather fields in response and that may not be ideal for your application. So provided below you could enable or disable the fields you would like to remove from your response.

If you wish any fields to not appear in the json response then simply uncheck that fields below and click on Save button at the bottom of screen.

[axolotl-git]

But, at this point can't other fields be added too? Maybe under a setting "advanced weather data" or something like this?

[sebastinto]

But, at this point can't other fields be added too? Maybe under a setting "advanced weather data" or something like this?

Yeah ideally you'd have a way to select which data you want displayed and in which order.

A WEATHERCONFIG command could be added that would launch a WeatherConfigActivity dedicated to configuring what you want the WEATHER command to display.

Implementing something like this would require a substantial refactor though. 😅

[axolotl-git]

At this point a config file could be added

[sebastinto]

At this point a config file could be added

That or maybe the config could be saved as a json string to SharedPreferences since SharedPreferences is already used in the project?

I'd probably define the weather config as a data class and serialize it using kotlinx.serialization.

Something roughly like this (off the top of my head)?

import kotlinx.serialization.Serializable
import kotlinx.serialization.encodeToString
import kotlinx.serialization.json.Json
import kotlinx.serialization.decodeFromString

// define the config data class
@Serializable
data class Config(
    val someProp: Int,
    val anotherProp: String,
    // additional fields
)

// save to SharedPrefs
val jsonString = Json.encodeToString(Config)
sharedPrefs.edit().putString("config", jsonString).apply()

// read from SharedPrefs
val jsonString = sharedPrefs.getString("key", null)
val obj = jsonString?.let { Json.decodeFromString<Config>(it) }

A challenge would be to design the architecture so that handleResponse doesn't become a maze of conditional statements.

Also., I wonder if the weather data could be configured entirely via commands which would be neat but I can't quite define what that could look like.

[coderGtm]

Weather config is a possible solution but I think just using flags in the weather command will be an easier and familiar experience to users. We can modify the weather command to display all data by default. Users can then use flags like -temp -uv -humidity to display only specific parameters. Similar to sysinfo and other commands.

What do you guys think about it?

[axolotl-git]

I think is good, in the end people will end up making an alias anyway to automatically have the weather of their city

[sebastinto]

Users can then use flags like -temp -uv -humidity to display only specific parameters. Similar to sysinfo and other commands.

That's what I meant when I said " I wonder if the weather data could be configured entirely via commands". This would definitely be more in line with the concept of the launcher!

We can modify the weather command to display all data by default.

Since there are 100+ fields available, that'd be a wild output!

Wouldn't it be better to display the current fields as default? This would ensure backward compatibility / prevent forcing a change on current users. I think most users would be satisfied with the weather command output only containing the current fields as a sort "summary".

Then power users can use flags and aliases for granular control over what they want returned. But maybe everyone who uses Yantra Launcher is a "power user"? 😄

[axolotl-git]

But maybe everyone who uses Yantra Launcher is a "power user"? 😄

I do not want to judge anyone but i seen some pretty wild(or stupid) questions on the discord server XD so i'd say no

Wouldn't it be better to display the current fields as default? This would ensure backward compatibility / prevent forcing a change on current users. I think most users would be satisfied with the weather command output only containing the current fields as a sort "summary".

I agree with you

[coderGtm]

This brings us back to config file. A default list of args cannot be specified for everyone. I get the backward compatibility and summary part and agree with it, but showing some parameters by default without any args is unpredictable.

So a config using shared preferences in the settings where our default args are pre-defined is a more predictable approach for users. Something like a list with checkboxes or an output template.

Yes we lose the simplicity of cmd line args here, but then there is also the problem of handling location names with spaces. For example, in

wearher new york -uv

We have no way to deterministically recognise when the flags begin since Yantra Launcher does not use quotes for values with space, ofc for simplicity.

[sebastinto]

weather new york -uv

I think I can make this work!

I really like the simplicity of cmd line args:

weather new york => returns default weather info

weather new york -uv => returns uv info only

weather paris -uv -temp => returns uv and temp info
alias parisweather = weather paris -uv -temp
parisweather => returns uv and temp info for Paris

weather list => returns all available weather args

Would you be open to a PR implementing this? I would close the current one since it would no longer be relevant.

[coderGtm]

I think I can make this work!

How will you approach it. What if the location name contains a hyphen in it?

[sebastinto]

I think I can make this work!

How will you approach it. What if the location name contains a hyphen in it?

TBD but I'd probably take a test-driven development approach to ensure edge cases like the one you mentioned are handled correctly. This seems like a fun challenge!

[sebastinto]

WIP but promising...

[coderGtm]

Ok if you can handle it then I am definitely open to a PR. Would be the best of both worlds. All the best and let me know if you need any assistance!

[sebastinto]

Supplanted by #428