You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That category is then used by `WeatherTheme` to select one of the three existing background assets:
73
+
74
+
-`sunny` -> `Sunny`
75
+
-`cloudy` -> `Cloudy`
76
+
-`rainy` -> `Rainy`
77
+
78
+
The background is therefore still driven by the app's primary condition and remains intentionally simple. It does **not** switch to a unique background per fine-grained OpenWeather condition code.
79
+
80
+
### Bundled Weather Icon Logic
81
+
82
+
In addition to the coarse background category, the app now keeps the primary OpenWeather condition payload for icon resolution:
83
+
84
+
-`weather.id`
85
+
-`weather.main`
86
+
-`weather.description`
87
+
88
+
The icon pipeline uses `weather.id` as the primary lookup key because it is the most stable field for condition matching. That ID is mapped to the provided bundled weather icon assets instead of relying only on SF Symbols.
89
+
90
+
The bundled icon set is treated as the app's primary weather icon library. OpenWeather conditions are mapped into the closest available asset in that set. For example:
91
+
92
+
- clear sky maps to the bundled sun icon
93
+
- few clouds maps to the bundled partly cloudy icon
94
+
- heavier cloud coverage maps to bundled cloud-based icons
95
+
- drizzle maps to the bundled drizzle icon
96
+
- light rain maps to the bundled light-rain icon
97
+
- heavy rain maps to the bundled heavy-rain icon
98
+
- thunder and thunderstorm conditions map to bundled storm icons
99
+
- snow and heavy snow map to bundled snow assets
100
+
- sleet and freezing-rain style conditions map to the bundled hailstorm asset
101
+
- fog and haze map to a bundled cloud asset
102
+
- strong wind, dust, sand, squall, and tornado families map to the bundled heavy-wind asset
103
+
104
+
Some provided assets are intentionally **not** used for weather-condition matching in the current app because they represent celestial or time-of-day imagery rather than weather conditions themselves. That includes icons such as:
105
+
106
+
- sunrise
107
+
- sunset
108
+
- eclipse
109
+
- moon variants
110
+
111
+
Those assets are excluded from the OpenWeather condition mapping because this app is focused on weather-state presentation, not astronomy-state presentation.
112
+
113
+
### Fallback Behavior
114
+
115
+
The icon mapping system follows a fallback chain so the UI remains resilient if OpenWeather returns an unmapped or unexpected condition:
116
+
117
+
1. map from `weather.id`
118
+
2. if needed, fall back to `weather.main` / `weather.description` heuristics
119
+
3. if still unresolved, fall back to the bundled cloud icon as the default asset
120
+
4. if the expected bundled asset cannot be loaded, fall back to an SF Symbol
121
+
122
+
This means the app now prefers the provided weather icons at runtime, while still keeping a safe fallback path so the UI can render even if an icon is missing or a new OpenWeather condition appears.
123
+
124
+
### Architectural Intent
125
+
126
+
The project now separates:
127
+
128
+
-**weather category for backgrounds**
129
+
-**weather icon asset for condition display**
130
+
131
+
This keeps the background logic stable and easy to reason about, while allowing the forecast rows and current-condition UI to become much more specific without changing the rest of the app's visual architecture.
132
+
39
133
## Configuration
40
134
41
135
The current testing configuration is defined in [AppConfiguration.swift](/Users/blessingmabunda/Documents/WeatherApp/WeatherApp/App/AppConfiguration.swift).
0 commit comments