Refactor state management into context singletons

[Copilot]

Centralize mutable application state in dedicated context singletons so view models remain transient and services/factories stay stateless.

• Context model

  • Added individual internal context classes (NavigationContext, VolumeContext, MediaListContext, MediaViewModelFactoryContext, AlbumFactoryContext, ArtistFactoryContext, LibVlcContext, TransportControlsContext, NotificationContext, CastContext, WindowContext, LibraryContext, LastPositionContext) in Screenbox.Core/Contexts.
  • Registered each context class as a singleton in DI.

• View models to context-backed state

  • CommonViewModel, VolumeViewModel, and MediaListViewModel now pull/persist state through injected context singletons, allowing transient lifetimes while retaining user/session data.
  • Playlist, media buffer, and navigation UI margins now survive VM recreation without direct view bindings.

• Services and factories statelessness

  • Media/album/artist factories, LibVlcService, transport controls, notifications, cast, window, library services, and last-position tracker now store mutable caches in their respective context classes rather than instance fields.

Example:

// DI
services.AddSingleton<VolumeContext>();

// VM consuming shared state
public VolumeViewModel(ISettingsService settings, VolumeContext volumeContext)
{
    var state = volumeContext;
    _volume = state.IsInitialized ? state.Volume : settings.PersistentVolume;
    state.Volume = _volume;
}

Original prompt

Refactor state management in the Screenbox.Core project. Create a model called SessionContext. Add this model into DI as a singleton. Move all application states that reside in view models, services, and factories into this session context, so that all view models can be transient and services and factories should be stateless. SessionContext is a pure model; don't use observable properties or collections. Do not bind directly to the context from views. SessionContext should be internal to Screenbox.Core.

---

💡 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.

[huynhsontung]

@copilot Good start. But since SessionContext is just a collection of smaller state objects, it's probably better to register these state objects to the DI directly instead of going through the SessionContext object. Each class should be in its own file. Put them in a new folder called Contexts at the root of Screenbox.Core project. Rename the classes if necessary.

[Copilot]

@copilot Good start. But since SessionContext is just a collection of smaller state objects, it's probably better to register these state objects to the DI directly instead of going through the Sessio...

States are now registered individually as singletons under a new Contexts folder (one class per file) and injected directly where needed. Changes in abdd839.

[huynhsontung]

@copilot rename the ...State classes to ...Context class instead since they are under Contexts folder

[Copilot]

@copilot rename the ...State classes to ...Context class instead since they are under Contexts folder

Renamed all context classes to *Context (NavigationContext, VolumeContext, etc.) and updated DI/injections accordingly in b42a38e.