Add shared ConfigWidget page, JSON-based widget layout DSL with Mapbox-style expressions, optimized dual reactive StateFlow-based widget update system, build-time widget config generation, live preview development mode, cross-platform localization supp...

[Copilot]

• Glance Generator Fixes - COMPLETE ✅✅

  • Fixed double data prefix: data.iconPath no longer becomes data.data.iconPath
  • Fixed unnecessary string interpolation: item.day used directly instead of "${item.day}"
  • Cleaner generated code: Property access is more direct and readable
  • All widgets regenerated: All 6 widgets updated with correct property access

• Widget Settings Architecture - Native-Side Per-Widget Instance Storage ✅✅✅✅

  • Settings stored in widget config: Each widget instance has its own independent settings
  • JSON schema definitions: Settings defined with type/default/title/description (as localization keys) in widget JSON files
  • Native-side initialization: Android WeatherWidgetManager and iOS managers initialize settings from JSON schemas
  • Kind config defaults: Widget kind configs initialized with settings defaults from JSON
  • Instance config creation: Settings copied from kind config to instance config on widget creation
  • Config passing: All 6 Android widgets load and pass config to generated content
  • All generators updated: Glance, Swift, and NativeScript access settings via config.settings
  • Function signatures updated: Added config parameter to all generated widget functions
  • Independent widget instances: Multiple widgets of same type can have different setting values
  • Settings backup/restore: Settings saved with widget config, no separate storage needed
  • Localization keys: Settings titles/descriptions use localization keys for ConfigWidget.svelte

• Reactive Widget Update Architecture - COMPLETE ✅✅✅✅✅✅✅

  • Dual StateFlow architecture: WidgetDataStore for weather data + WidgetConfigStore for widget configs
  • Automatic recomposition: All 6 widgets use collectAsState to observe both data and config changes
  • Optimized widget-specific observation: Widgets only observe their own settings, not entire config map
  • Eliminated cross-widget recomposition: Settings changes only affect the specific widget that changed
  • No manual update() calls: Removed forceGlanceUpdate() and all widget.update() calls
  • Glance best practices: Follows official Glance documentation for reactive widget updates
  • Persistent cache: SharedPreferences backup for cold starts, loads into StateFlow on init
  • Clean architecture: Data layer (StateFlow) cleanly separated from presentation (Compose)
  • provideGlance stays active: Composition observes StateFlows and reacts to changes automatically
  • Settings-only updates: Config changes trigger recomposition without data refetch
  • Performance optimized: distinctUntilChanged() ensures recomposition only when settings actually change

• Build-Time Widget Config Generation - COMPLETE ✅✅✅✅✅✅✅✅

  • Generator created: generate-widget-kind-configs.ts generates TS/Kotlin/Swift config files
  • Single source of truth: Widget JSON schemas define all settings defaults
  • Cross-platform consistency: Same defaults used on Android, iOS, and TypeScript
  • No code duplication: Settings extracted once, generated for all platforms
  • Immediate availability: Configs available at app start, no async loading or runtime JSON parsing
  • Type-safe generated code: Properly typed for each platform
  • Build integration: Runs automatically on setup, manual via npm script
  • iOS parity: WidgetSettings.swift now matches Android WeatherWidgetManager.kt architecture
  • Documented: README explains generator, usage, benefits, and workflow

Widget Settings Architecture

Widget settings are now stored per-instance in the widget configuration object and initialized entirely on the native side using build-time generated configurations:

Benefits

• Per-widget customization: Each widget instance maintains independent settings (e.g., one clock widget can have bold text while another doesn't)
• Native-side management: Settings initialization and defaults handled by Android/iOS widget managers using generated configs
• No global pollution: Settings don't interfere across widget instances
• Backup/restore: Settings are automatically backed up with widget config
• Schema-driven: Settings schema lives with widget layout definition (single source of truth)
• Type-safe defaults: All settings have defined types and default values from JSON schema
• Localized UI: Settings titles/descriptions use localization keys for multi-language support
• Build-time generation: Configs generated at build time, eliminating runtime JSON parsing
• Cross-platform consistency: Same defaults across Android, iOS, and TypeScript

Implementation

Settings Definition (in widget JSON):

{
  "settings": {
    "clockBold": {
      "type": "boolean",
      "default": true,
      "title": "widget_clock_bold_title",
      "description": "widget_clock_bold_description"
    }
  }
}

Build-Time Config Generation:

• Generator: generate-widget-kind-configs.ts reads widget JSON schemas
• Output: TypeScript, Kotlin, and Swift files with pre-initialized configs
• Integration: Runs on npm install via setup script
• Files Generated:
  • app/services/widgets/WidgetKindConfigs.ts
  • App_Resources/Android/.../WidgetKindConfigs.generated.kt
  • App_Resources/iOS/.../WidgetKindConfigs.generated.swift

Native-Side Initialization:

• Android: WeatherWidgetManager uses WidgetKindConfigs.createDefaultKindConfig()
• iOS: WidgetSettings uses WidgetKindConfigs.getKindConfig()
• Kind configs initialized from generated code (no runtime JSON parsing)
• Instance configs get settings copied from kind config on creation
• All widgets load config and pass to generated content functions

Settings Access (in generators):

• Android Glance: config.settings?.get("clockBold") as? Boolean ?: true
• iOS Swift: config.settings?["clockBold"] as? Bool ?? true
• NativeScript: config.settings?.clockBold ?? true

Config Flow:

1. Widget JSON defines settings schema with localization keys for title/description
2. Build-time generator creates platform-specific config files from JSON schemas
3. Native widget managers use generated configs to initialize kind configs
4. Instance config created with settings copied from kind config
5. Widget loads config and passes to generated content
6. Generated content accesses config.settings with proper fallbacks
7. ConfigWidget.svelte loads localized titles/descriptions using keys

Updates: When settings are changed in the widget configuration UI, the widget config is updated and the widget re-renders with the new values automatically via reactive StateFlow.

This architecture ensures each widget instance can be customized independently while maintaining clean, schema-driven defaults, type safety, proper localization support, and cross-platform consistency. All initialization happens on the native side (Android/iOS) using build-time generated configs, eliminating runtime JSON parsing and code duplication, with the TypeScript side only displaying the settings UI with localized strings.

Reactive Widget Update Architecture

Widgets now use an optimized dual reactive StateFlow-based architecture that follows Glance best practices for automatic updates:

Problem Solved

Previously, calling widget.update() did not consistently trigger provideGlance because Glance's documentation states: "update() and updateAll() do not restart provideGlance if it is already running." This caused widgets to not update reliably when data or settings changed.

Solution

Implemented an optimized dual reactive architecture where:

• WidgetDataStore: Singleton object managing a StateFlow<Map<Int, WeatherWidgetData>> that holds all widget weather data
• WidgetConfigStore: Singleton object with getWidgetSettingsFlow(widgetId) method that provides widget-specific settings observation
• Widget-specific observation: Each widget observes only its own settings via filtered StateFlow, not the entire config map
• Automatic recomposition: When data or config changes, Compose automatically triggers recomposition only for affected widgets
• No manual updates: Removed all forceGlanceUpdate() and widget.update() calls throughout the codebase
• Performance optimization: distinctUntilChanged() ensures recomposition only when settings actually change

Implementation

WidgetDataStore (in WeatherWidgetManager):

object WidgetDataStore {
    private val _widgetData = MutableStateFlow<Map<Int, WeatherWidgetData>>(emptyMap())
    val widgetData: StateFlow<Map<Int, WeatherWidgetData>> = _widgetData.asStateFlow()
    
    fun updateWidgetData(widgetId: Int, data: WeatherWidgetData) {
        _widgetData.update { current -> current + (widgetId to data) }
    }
}

WidgetConfigStore (in WeatherWidgetManager):

object WidgetConfigStore {
    private val _widgetConfigs = MutableStateFlow<Map<Int, WidgetConfig>>(emptyMap())
    val widgetConfigs: StateFlow<Map<Int, WidgetConfig>> = _widgetConfigs.asStateFlow()
    
    fun getWidgetSettingsFlow(widgetId: Int): StateFlow<Map<String, Any?>?> {
        return widgetConfigs
            .map { configs -> configs[widgetId]?.settings }
            .distinctUntilChanged()
            .stateIn(
                scope = CoroutineScope(SupervisorJob() + Dispatchers.Default),
                started = SharingStarted.Eagerly,
                initialValue = _widgetConfigs.value[widgetId]?.settings
            )
    }
    
    fun updateWidgetConfig(widgetId: Int, config: WidgetConfig) {
        _widgetConfigs.update { current -> current + (widgetId to config) }
    }
}

Widget provideGlance (all 6 widgets):

override suspend fun provideGlance(context: Context, id: GlanceId) {
    val widgetId = getWidgetId(id)
    WeatherWidgetManager.loadWidgetDataCache(context)
    WeatherWidgetManager.getAllWidgetConfigs(context)
    
    provideContent {
        val dataMap by WidgetDataStore.widgetData.collectAsState()
        val widgetSettings by WidgetConfigStore.getWidgetSettingsFlow(widgetId).collectAsState()
        val data = dataMap[widgetId]
        val widgetConfig = WidgetConfig(settings = widgetSettings)
        
        if (data != null) {
            WidgetContent(context, widgetConfig, data, size)
        } else {
            LoadingState()
        }
    }
}

Benefits

• Reliable updates: Widgets always update when data or settings change, no random failures
• Glance best practices: Follows official Glance documentation recommendations
• Reactive by design: Pure Compose reactivity - changes automatically trigger UI updates
• Clean architecture: Clear separation between data layer (StateFlow) and presentation (Compose)
• Performance optimized: Widget A's settings changes don't cause widget B to recompose
• Efficient filtering: map() and distinctUntilChanged() ensure minimal recomposition
• provideGlance stays active: Observes for changes efficiently without restarting
• Simplicity: No complex update orchestration logic needed
• Settings isolation: Config changes trigger recomposition without triggering weather data refetch

Performance Impact

• Before optimization: Changing any widget's config → all widgets recompose
• After optimization: Changing widget A's settings → only widget A recomposes
• Example: User has 5 clock widgets, changes bold setting on widget 1 → only widget 1 updates, not all 5

Data Persistence

Both widget data and configs are cached in SharedPreferences for cold starts:

• loadWidgetDataCache(): Initializes WidgetDataStore from persisted data on app/widget startup
• saveWidgetDataCache(): Persists data for restoration after process death
• getAllWidgetConfigs(): Initializes WidgetConfigStore from persisted configs
• saveWidgetConfig(): Persists config and updates WidgetConfigStore StateFlow
• StateFlows provide the live, in-memory reactive layer on top of persistent storage

This architecture ensures widgets update reliably and reactively for both weather data changes and settings changes, while maintaining proper data persistence, keeping these concerns cleanly separated, and optimizing performance by eliminating unnecessary cross-widget recomposition.

Build-Time Widget Config Generation

Widget kind configurations are now generated at build time from JSON schemas, ensuring cross-platform consistency and eliminating code duplication:

Generator Implementation

• Script: widget-layouts/generators/generate-widget-kind-configs.ts
• Source: Reads widget JSON schemas from widget-layouts/widgets/
• Extracts: Settings definitions with type, default, title, and description
• Generates: TypeScript, Kotlin, and Swift files with pre-initialized configs

Generated Files

1. TypeScript: app/services/widgets/WidgetKindConfigs.ts - For main app
2. Kotlin: App_Resources/Android/.../WidgetKindConfigs.generated.kt - For Android
3. Swift: App_Resources/iOS/.../WidgetKindConfigs.generated.swift - For iOS

Build Integration

• Automatic: Runs on npm install via postinstall → setup script chain
• Manual: npm run generate:widget-kind-configs from root, or npm run generate:kind-configs from widget-layouts/
• Documentation: README in widget-layouts/generators/ explains usage and workflow

Native Manager Updates

Android WeatherWidgetManager.kt:

• Removed loadDefaultSettingsForKind() runtime JSON parsing
• Now uses WidgetKindConfigs.createDefaultKindConfig() from generated code
• Kind configs initialized immediately at app start with no async loading

iOS WidgetSettings.swift:

• Enhanced to match Android WeatherWidgetManager.kt architecture
• Uses WidgetKindConfigs.getKindConfig() from generated code
• Added proper WidgetConfig struct with settings: [String: Any]? field
• Implemented Codable with AnyCodable helper for settings serialization
• Kind and instance config management now mirrors Android implementation

Benefits

• Single source of truth: JSON schemas define all settings defaults
• No code duplication: Settings extracted once, generated for all platforms
• Cross-platform consistency: Same defaults on Android, iOS, and TypeScript
• Immediate availability: Configs available at app start, no async loading
• Type-safe: Generated code properly typed for each platform
• Performance: Eliminates runtime JSON parsing overhead
• Maintainability: Settings defined once, used everywhere
• iOS parity: iOS implementation now matches Android architecture

Workflow

1. Define settings in widget JSON schemas (widget-layouts/widgets/*.json)
2. Run generator (automatically on npm install or manually)
3. Generator creates platform-specific config files
4. Android/iOS managers use generated configs for kind defaults
5. Instance configs created from kind configs with settings copied
6. Settings changes update instance configs reactively

Original prompt

Summary

Add a shared "Configure Widget" page to configure widgets (location, model, refresh rate, and widget-specific options). This page should show a live preview of the widget at the top (rendering the native widget view on Android via the existing android/WidgetPreview.ts example; attempt iOS embedding but provide a safe fallback). Wire the page to WidgetConfigManager for loading/saving configs and reuse existing Settings UI pieces (ListItemAutoSize, SelectCity.svelte, SelectPositionOnMap.svelte). Add an Android Activity to open the page when Android requests widget configuration (android/widgetconfigactivity.ts) and close the activity when the modal is dismissed.

Goals / Acceptance criteria

• New ConfigWidget page/component that:
  • Shows a preview area at the top that attempts to mount the native widget view. On Android use the existing android/WidgetPreview.ts helper. On iOS attempt to load the native widget extension class but fallback to a static preview image/background if not possible.
  • Uses WidgetConfigManager to load the widget config for the given widget class and id, show fields and save changes automatically when changed.
  • Uses the same ListItemAutoSize UI pattern as Settings.svelte for each configurable section.
  • Uses SelectCity.svelte and SelectPositionOnMap.svelte for picking location where appropriate.
  • Exposes widget-specific settings where needed (example: clock font weight).
  • Exposes refresh rate common setting.
• Modify Settings.svelte
  • Add a sub-section for "Widgets" listing known widget classes and an item to open ConfigWidget for each class.
• Android
  • Implement android/widgetconfigactivity.ts to parse the incoming intent, map to the widget class and id, open the ConfigWidget page as a modal and finish the activity when the modal is closed.
• Config changes persist via WidgetConfigManager immediately when changed.

Files to add/modify (detailed)

1. Add new page: src/pages/ConfigWidget.svelte

• Props/parameters: widgetClass (string), widgetId (string-or-number), modalMode (boolean optional)
• Behavior:
  • OnMount: load config from WidgetConfigManager.get(widgetClass, widgetId) (or appropriate API) and populate local reactive state.
  • Render preview area at top using component. The preview should show a phone-home-like background depending on platform (simple gradient or blur). The widget preview will receive the same config as the editing form so it updates live.
  • Render settings sections using ListItemAutoSize (imported from Settings.svelte usage). For location settings use SelectCity.svelte or SelectPositionOnMap.svelte. For generic options use plain toggles/inputs. For widget-specific settings, render conditional controls (e.g., if widgetClass === 'clock', show font weight select).
  • When any setting changes, call WidgetConfigManager.save(widgetClass, widgetId, config) (or set & persist) so changes are saved immediately.
  • Expose a "Close" button that either dismisses the modal or navigates back depending on usage.

2. New component: src/components/WidgetPreview.svelte

• Platform-aware component that mounts native widget view on Android by using the existing android/WidgetPreview.ts helper. On iOS attempt to instantiate the native widget view from the extension's class (best effort) and fallback to a stylized static preview if unavailable.
• Accepts the widgetClass and widgetConfig props and forwards them to the native view if possible.

3. Modify: src/pages/Settings.svelte

• Add a new section labelled "Widgets" (re-using ListItemAutoSize) containing rows per widget class. Each row opens ConfigWidget page for that widget class. Also add a global widgets refresh rate setting accessible from here.

4. Modify/Add: android/widgetconfigactivity.ts

• Implement handling of AppWidget configuration intent: extract widget id and widget class from intent extras.
• Launch an activity/page that mounts the app and opens ConfigWidget as a modal for that widgetClass/widgetId.
• When modal is closed, call setResult(RESULT_OK) and finish() so the system accepts the configuration.
• Use existing android/WidgetPreview.ts code as reference for mounting native views.

5. Tests / Examples

• Add a small example in docs/ or README section describing how to configure widgets from Settings and how Android launches the config activity.

Assumptions & notes for reviewers

• I couldn't verify exact APIs or filenames of WidgetConfigManager, ListItemAutoSize, SelectCity.svelte, and SelectPositionOnMap.svelte in the repo. The implementation will import them using the paths used elsewhere in the repo (e.g. src/lib/WidgetConfigManager or src/stores/WidgetConfigManager). If imports fail CI will point to the exact path differences and I'll update.
• Android preview mounting relies on the example android/WidgetPreview.ts you already added. iOS embedding of extension widget views may require moving some code or exposing a small wrapper in the extension target; beca...

This pull request was created as a result of the following prompt from Copilot chat.

Summary

Add a shared "Configure Widget" page to configure widgets (location, model, refresh rate, and widget-specific options). This page should show a live preview of the widget at the top (rendering the native widget view on Android via the existing android/WidgetPreview.ts example; attempt iOS embedding but provide a safe fallback). Wire the page to WidgetConfigManager for loading/saving configs and reuse existing Settings UI pieces (ListItemAutoSize, SelectCity.svelte, SelectPositionOnMap.svelte). Add an Android Activity to open the page when Android requests widget configuration (android/widgetconfigactivity.ts) and close the activity when the modal is dismissed.

Goals / Acceptance criteria

• New ConfigWidget page/component that:
  • Shows a preview area at the top that attempts to mount the native widget view. On Android use the existing android/WidgetPreview.ts helper. On iOS attempt to load the native widget extension class but fallback to a static preview image/background if not possible.
  • Uses WidgetConfigManager to load the widget config for the given widget class and id, show fields and save changes automatically when changed.
  • Uses the same ListItemAutoSize UI pattern as Settings.svelte for each configurable section.
  • Uses SelectCity.svelte and SelectPositionOnMap.svelte for picking location where appropriate.
  • Exposes widget-specific settings where needed (example: clock font weight).
  • Exposes refresh rate common setting.
• Modify Settings.svelte
  • Add a sub-section for "Widgets" listing known widget classes and an item to open ConfigWidget for each class.
• Android
  • Implement android/widgetconfigactivity.ts to parse the incoming intent, map to the widget class and id, open the ConfigWidget page as a modal and finish the activity when the modal is closed.
• Config changes persist via WidgetConfigManager immediately when changed.

Files to add/modify (detailed)

1. Add new page: src/pages/ConfigWidget.svelte

• Props/parameters: widgetClass (string), widgetId (string-or-number), modalMode (boolean optional)
• Behavior:
  • OnMount: load config from WidgetConfigManager.get(widgetClass, widgetId) (or appropriate API) and populate local reactive state.
  • Render preview area at top using component. The preview should show a phone-home-like background depending on platform (simple gradient or blur). The widget preview will receive the same config as the editing form so it updates live.
  • Render settings sections using ListItemAutoSize (imported from Settings.svelte usage). For location settings use SelectCity.svelte or SelectPositionOnMap.svelte. For generic options use plain toggles/inputs. For widget-specific settings, render conditional controls (e.g., if widgetClass === 'clock', show font weight select).
  • When any setting changes, call WidgetConfigManager.save(widgetClass, widgetId, config) (or set & persist) so changes are saved immediately.
  • Expose a "Close" button that either dismisses the modal or navigates back depending on usage.

2. New component: src/components/WidgetPreview.svelte

• Platform-aware component that mounts native widget view on Android by using the existing android/WidgetPreview.ts helper. On iOS attempt to instantiate the native widget view from the extension's class (best effort) and fallback to a stylized static preview if unavailable.
• Accepts the widgetClass and widgetConfig props and forwards them to the native view if possible.

3. Modify: src/pages/Settings.svelte

• Add a new section labelled "Widgets" (re-using ListItemAutoSize) containing rows per widget class. Each row opens ConfigWidget page for that widget class. Also add a global widgets refresh rate setting accessible from here.

4. Modify/Add: android/widgetconfigactivity.ts

• Implement handling of AppWidget configuration intent: extract widget id and widget class from intent extras.
• Launch an activity/page that mounts the app and opens ConfigWidget as a modal for that widgetClass/widgetId.
• When modal is closed, call setResult(RESULT_OK) and finish() so the system accepts the configuration.
• Use existing android/WidgetPreview.ts code as reference for mounting native views.

5. Tests / Examples

• Add a small example in docs/ or README section describing how to configure widgets from Settings and how Android launches the config activity.

Assumptions & notes for reviewers

• I couldn't verify exact APIs or filenames of WidgetConfigManager, ListItemAutoSize, SelectCity.svelte, and SelectPositionOnMap.svelte in the repo. The implementation will import them using the paths used elsewhere in the repo (e.g. src/lib/WidgetConfigManager or src/stores/WidgetConfigManager). If imports fail CI will point to the exact path differences and I'll update.
• Android preview mounting relies on the example android/WidgetPreview.ts you already added. iOS embedding of extension widget views may require moving some code or exposing a small wrapper in the extension target; because that may be sensitive or infeasible in this PR I will provide a graceful fallback and include TODO comments pointing to where to improve iOS live preview once we can access the extension widget classes.
• The ConfigWidget page is designed to be reusable across widgets; widget-specific fields are handled via a small per-widget switch inside the page. If you prefer a plugin-based per-widget component approach I can refactor later.

What I'll change in this PR (concrete list)

• Add src/pages/ConfigWidget.svelte
• Add src/components/WidgetPreview.svelte
• Update src/pages/Settings.svelte to add Widgets section
• Add android/widgetconfigactivity.ts (or update the existing file if present)
• Add short docs/README snippet: docs/widget-config.md

Please confirm you want me to open the PR now. If yes I'll create the branch and open the PR with the above changes. If you prefer a different file layout or names please tell me which paths to use before I create the PR.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[farfromrefug]

@copilot * in ConfigWidget, use widgetService to update all widgets

• widgetconfigactivity cant open ConfigWidget with showModal. it needs to "mount" it. Look at android/floatingactivity.ts to see how it is done in setActivityContent
• implement the widget Preview for both ios and android. It should manage to render a native widget based on the widget "type" and set fake data into it.
• use a ios or android home background image behind the widget preview to make it looks like it is a "view" on the home
• for widget notes. use the ANDROID test directly in the labet text property

[Copilot]

@copilot * in ConfigWidget, use widgetService to update all widgets

• widgetconfigactivity cant open ConfigWidget with showModal. it needs to "mount" it. Look at android/floatingactivity.ts to see how...

Addressed all feedback in commit 57de2f7:

• ConfigWidget: Now uses widgetService.updateWidget(widgetId) instead of direct widget manager calls
• widgetconfigactivity.ts: Rewritten to use setActivityContent pattern from floatingactivity.ts with resolveComponentElement to mount the Svelte component directly
• Widget Preview: Added home background using the existing ~/assets/images/pattern.png pattern image, with a styled preview card showing fake data (temperature, location)
• Widget notes: Simplified to use __ANDROID__ test directly in the label text property

[farfromrefug]

@copilot the ConfigWidget still uses a "placeholder" for the actual widget rendering.
I need you implement that WidgetPreview extending N View (see android/WidgetPreview.ts) for a "shell". It needs to be able to render the native widget view like HourlyWeatherWidget on android (from App_Resources/Android/src/main/java/com/akylas/weather/widgets/HourlyWeatherWidget.kt) or HourlyWeatherWidget on ios(from App_Resources/iOS/extensions/widgets/AllWeatherWidgets.swift). On ios the trick is that AllWeatherWidgets.swift is actually in the extension project. I am not sure to make it visible for my N app

[Copilot]

@copilot the ConfigWidget still uses a "placeholder" for the actual widget rendering.
I need you implement that WidgetPreview extending N View (see android/WidgetPreview.ts) for a "shell". It needs ...

Implemented native WidgetPreview component in commit 0449e37:

Android (android/WidgetPreview.ts):

• Complete native View implementation that renders widget UI based on widget type
• Supports all widget types: SimpleWeatherWidget, HourlyWeatherWidget, DailyWeatherWidget, SimpleWeatherWithClockWidget, SimpleWeatherWithDateWidget, ForecastWeatherWidget
• Creates native Android views (LinearLayout, TextView, TextClock, etc.) that mimic actual widget appearance
• Uses fake weather data for preview (8°C, Partly Cloudy, hourly/daily forecasts)
• Accepts widgetClass and locationName properties

iOS (components/WidgetPreview.svelte):

• Falls back to a styled preview since AllWeatherWidgets.swift is in the extension project and cannot be directly embedded in the main NativeScript app
• Extension views are sandboxed separately from the main app bundle

The ConfigWidget now uses the WidgetPreview component which shows a native-looking widget preview on Android.

[farfromrefug]

@copilot Is it possible to refactor the ios widgets extension code (in App_Resources/iOS/extensions/widgets) so that classes like SimpleWeatherWithClockWidgetView (you would do that for all widgets in App_Resources/iOS/extensions/widgets/AllWeatherWidgets.swift) are also visible by the app so that i can render them inside the app?
You would need to make sure everything builds correctly, which means alls classes struct, methods... used in SimpleWeatherWithClockWidgetView can be "compiled within the app.
The idea is to be able to provide fake entry to the view to render them within WidgetPreview.ts N component.

If possible use the same technique on android by refactoring App_Resources/Android/src/main/java/com/akylas/weather/widgets/SimpleWeatherWidget.kt and other widget classes so that WeatherContent can be rendered with in the app "out" of glance. I guess they should be Composable that i can "instantiate" inside N. If it is possible do it for all widgets and use those new view for WidgetPreview.ts.
Move WidgetPreview.ts in a shared directory (not android). Same thing it should be possible to pass fake data to those WeatherContent views.

[Copilot]

@copilot Is it possible to refactor the ios widgets extension code (in App_Resources/iOS/extensions/widgets) so that classes like SimpleWeatherWithClockWidgetView (you would do that for all widgets in...

After analyzing the widget code structures, this refactoring has significant architectural challenges:

iOS Challenge:
The SwiftUI widget views (SimpleWeatherWidgetView, etc.) depend on:

• WidgetKit framework (only available to extension targets)
• @Environment(\.widgetFamily) - widget-only environment value
• containerBackground(for: .widget) - extension-only API
• WeatherTimelineEntry - tied to TimelineEntry protocol

These cannot be compiled in the main app target because WidgetKit APIs are sandboxed to extensions.

Android Challenge:
The Glance composables use:

• GlanceModifier, GlanceTheme - Glance-specific, not Jetpack Compose
• provideContent {} - Glance rendering context
• LocalSize, LocalContext from Glance package

Glance composables cannot be rendered directly in a regular Android View hierarchy - they're designed exclusively for app widgets.

Alternative Approaches:

1. Keep the current approach: Native preview views in WidgetPreview.ts that mimic widget appearance using standard Android Views/TextViews
2. Create duplicate "preview" versions of the widget layouts using standard Jetpack Compose (not Glance) for Android, and UIKit/SwiftUI (without WidgetKit) for iOS
3. Use screenshots/images of widgets for preview

The current implementation in WidgetPreview.ts already renders native Android views that closely match widget appearance. Would you prefer I pursue option 2 (create separate preview-only composables/views)?

[farfromrefug]

@copilot ok i get it is impossible. There is another possibility. What about making widgets design follow a JSON "architecture" defining the design: layout,views, view properties, colors, weather data content key(path).
If possible we could then create a mapping/language translator for all platforms(android glance, ios widgets, N view rendering) to get the same layout.
This would also ensure full "correspondance" between android/ios widgets and allow easy maintenance.
The only think would to be have those "json" defining layout be available to all platforms possibly from the same json files in the repo.
If you can implement all that:

• a shared json schema defining a widget layout
• json with the full layout for all widgets
• parser/translator which creates the widget content view in the ios widgets extension, in android glance, and in N for the WidgetPreview.ts
• even create also a node js version which would render the widgets as image (so i guess a parser/translator for html). That way i can generate previews for widgets, or images to render on the readme

[farfromrefug]

@copilot i need the same thing for widgetConfig, i need the widget to update when the "settings" section of a widget settings gets update (only settings as others trigger weather data request)
Implement it

[Copilot]

@copilot i need the same thing for widgetConfig, i need the widget to update when the "settings" section of a widget settings gets update (only settings as others trigger weather data request)
Impleme...

Implemented in commit 2415e65.

WidgetConfigStore with reactive StateFlow architecture:

• All 6 widgets now observe WidgetConfigStore.widgetConfigs.collectAsState()
• When settings change via saveWidgetConfig(), StateFlow updates automatically trigger recomposition
• Settings changes don't trigger weather data refetch (only config recomposition)
• Parallel to WidgetDataStore: data updates independent from config updates

Flow:

1. User changes setting in ConfigWidget.svelte
2. saveWidgetConfig() persists to SharedPreferences
3. saveWidgetConfig() updates WidgetConfigStore StateFlow
4. Widgets observing config automatically recompose with new settings
5. No manual update() call, no weather data fetch - pure reactive updates

Settings like clock bold now instantly update widgets when changed.

[farfromrefug]

@copilot could we make the collectState only watch the settings section for the specific widget? Right now any widget will reload if any other widget updates its config (not only settings).
If you can implement it

[Copilot]

@copilot could we make the collectState only watch the settings section for the specific widget? Right now any widget will reload if any other widget updates its config (not only settings).
If you can...

Implemented in commit 5e1e578.

Each widget now observes only its own settings via getWidgetSettingsFlow(widgetId). The method uses map() and distinctUntilChanged() to create a widget-specific StateFlow that only emits when that particular widget's settings change.

Before: Changing any widget's config triggered recomposition in all widgets
After: Changing widget A's settings only recomposes widget A

Example: With 5 clock widgets on the home screen, changing bold setting on widget 1 now only updates widget 1, not all 5.

[farfromrefug]

@copilot i made some improvements. I need you to fill some blanks:

• the ios WidgetSettings.swift is not in line with the android WeatherWidgetManager.kt. It does not handle kind/instance config the same way. It does not create instance config nor kind config based on app/widget-layouts/widgets/. Fill the blanks and make the ios implementation in line with the latest android changes
• i need the kind configurations to be created on first run. I am now thinking that default kind configuration should be generated with webpack and "loaded" directly by the ios/android implementations so that we dont duplicate code on ios/android to generate the config and also that it is available right now app start

[Copilot]

@copilot i made some improvements. I need you to fill some blanks:

• the ios WidgetSettings.swift is not in line with the android WeatherWidgetManager.kt. It does not handle kind/instance config the s...

Implemented both requirements in commit 5acc327:

1. iOS WidgetSettings.swift now matches Android architecture:

• Uses generated WidgetKindConfigs instead of runtime JSON parsing
• getKindConfig() calls WidgetKindConfigs.createDefaultKindConfig(widgetKind:)
• WidgetConfig struct enhanced with settings: [String: Any]? field
• Proper Codable implementation with AnyCodable helper for settings
• Creates instance configs from kind defaults (matches Android flow)

2. Build-time kind config generation:

• Created generate-widget-kind-configs.ts generator script
• Reads widget JSON schemas and extracts settings defaults
• Generates 3 files:
  • app/services/widgets/WidgetKindConfigs.ts (TypeScript)
  • App_Resources/Android/.../WidgetKindConfigs.generated.kt (Kotlin)
  • App_Resources/iOS/.../WidgetKindConfigs.generated.swift (Swift)
• Integrated into setup script - runs on npm install
• Manual: npm run generate:widget-kind-configs

Benefits:

• Single source of truth (JSON schemas)
• No code duplication across platforms
• Configs available immediately at app start
• No runtime JSON parsing overhead
• Type-safe generated code

Both platforms now initialize kind/instance configs the same way from generated code.