Lobby: include HostUserId in GameStateDto and let client derive host status; update tests #7

tim · 2026-10-04T15:50:09Z

tim commented

2026-10-04 15:50:09 +00:00

Zusammenfassung
Diese Änderung sorgt dafür, dass der Client zuverlässig erkennen kann, ob der aktuell angemeldete Benutzer der Host einer Lobby ist. Dazu liefert der Server im GameStateDto jetzt zusätzlich das Feld HostUserId. Der Client bezieht IsHost fortan aus diesem Feld, statt alleiniger lokaler Annahme. Zusätzlich wurden Tests aktualisiert und das CI-Workflow angepasst, damit MAUI-Builds in CI-Umgebungen ohne Windows-Runtime-Pakete sauber laufen.

Was geändert wurde

SlipItIn.Shared/DTOs/GameStateDto.cs
- HostUserId (int) ergänzt
SlipItIn.Server/Services/GameService.cs
- GetGameStateAsync füllt HostUserId
SlipItIn/ViewModels/LobbyViewModel.cs
- IsHost wird aus GameState.HostUserId abgeleitet
SlipItIn.Server.Tests/GameHubTests.cs
- Mocks und Assertions aktualisiert, damit sie HostUserId berücksichtigen
SlipItIn.Server.Tests/GameServiceTests.cs
- Neuer Test GetGameStateAsync_IncludesHostUserId
.github/workflows/build.yml
- CI: Skip Windows TFM beim Restore (für CI/tooling), MAUI-Client in CI derzeit für Android bauen (net10.0-android)
SlipItIn/SlipItIn.csproj
- Windows-TFM nur wenn nicht SkipWindowsTargetFramework=true (ermöglicht CI ohne Windows runtime packs)

Warum

Problem: nach Reconnects oder in bestimmten UI-Flows wurde der Host-Status nicht zuverlässig gesetzt, sodass Host-only Aktionen (z. B. Spiel starten) nicht angezeigt wurden.
Lösung: serverseitig eindeutige Host-Id ausliefern, clientseitig nutzen — ein klarer, robustere Contract.

Verifikation / Testanleitung

Server-Unit-Tests: dotnet test SlipItIn.Server.Tests/SlipItIn.Server.Tests.csproj — alle Tests sollten grün sein (aktuell: 81).
Lokaler Build: dotnet build (Solution) / dotnet build SlipItIn.Server etc.
Manuelles App-Check:
1. Host: Lobby erstellen
2. Client B: Lobby beitreten
3. Beide Spieler auf "Bereit" klicken
4. Auf dem Host-Client sollte die Schaltfläche "Spiel starten (Host)" sichtbar und aktiv sein
CI: Der Workflow wurde so geändert, dass CI-Tools ohne Windows runtime-packs nicht mehr fehlschlagen; für echte Windows-Builds kannst du SkipWindowsTargetFramework weglassen.

Branch / PR

Branch: feature/host-userid-lobby-start
PR: #7
Letzter Commit auf Branch: 21cb57f (siehe PR-Commits)

Follow-ups (optional)

Automatisches Starten des Spiels, wenn alle Spieler bereit sind (serverseitig triggern) — kann separat implementiert werden.

Zusammenfassung Diese Änderung sorgt dafür, dass der Client zuverlässig erkennen kann, ob der aktuell angemeldete Benutzer der Host einer Lobby ist. Dazu liefert der Server im GameStateDto jetzt zusätzlich das Feld HostUserId. Der Client bezieht IsHost fortan aus diesem Feld, statt alleiniger lokaler Annahme. Zusätzlich wurden Tests aktualisiert und das CI-Workflow angepasst, damit MAUI-Builds in CI-Umgebungen ohne Windows-Runtime-Pakete sauber laufen. Was geändert wurde - SlipItIn.Shared/DTOs/GameStateDto.cs - HostUserId (int) ergänzt - SlipItIn.Server/Services/GameService.cs - GetGameStateAsync füllt HostUserId - SlipItIn/ViewModels/LobbyViewModel.cs - IsHost wird aus GameState.HostUserId abgeleitet - SlipItIn.Server.Tests/GameHubTests.cs - Mocks und Assertions aktualisiert, damit sie HostUserId berücksichtigen - SlipItIn.Server.Tests/GameServiceTests.cs - Neuer Test GetGameStateAsync_IncludesHostUserId - .github/workflows/build.yml - CI: Skip Windows TFM beim Restore (für CI/tooling), MAUI-Client in CI derzeit für Android bauen (net10.0-android) - SlipItIn/SlipItIn.csproj - Windows-TFM nur wenn nicht SkipWindowsTargetFramework=true (ermöglicht CI ohne Windows runtime packs) Warum - Problem: nach Reconnects oder in bestimmten UI-Flows wurde der Host-Status nicht zuverlässig gesetzt, sodass Host-only Aktionen (z. B. Spiel starten) nicht angezeigt wurden. - Lösung: serverseitig eindeutige Host-Id ausliefern, clientseitig nutzen — ein klarer, robustere Contract. Verifikation / Testanleitung - Server-Unit-Tests: dotnet test SlipItIn.Server.Tests/SlipItIn.Server.Tests.csproj — alle Tests sollten grün sein (aktuell: 81). - Lokaler Build: dotnet build (Solution) / dotnet build SlipItIn.Server etc. - Manuelles App-Check: 1. Host: Lobby erstellen 2. Client B: Lobby beitreten 3. Beide Spieler auf "Bereit" klicken 4. Auf dem Host-Client sollte die Schaltfläche "Spiel starten (Host)" sichtbar und aktiv sein - CI: Der Workflow wurde so geändert, dass CI-Tools ohne Windows runtime-packs nicht mehr fehlschlagen; für echte Windows-Builds kannst du SkipWindowsTargetFramework weglassen. Branch / PR - Branch: feature/host-userid-lobby-start - PR: https://git.krampitz.win/tim/SlipItIn/pulls/7 - Letzter Commit auf Branch: 21cb57f (siehe PR-Commits) Follow-ups (optional) - Automatisches Starten des Spiels, wenn alle Spieler bereit sind (serverseitig triggern) — kann separat implementiert werden.

tim added 1 commit 2026-10-04 15:50:10 +00:00

Lobby: include HostUserId in GameStateDto and let client derive host status; update tests

Build / build (pull_request) Failing after 1m0s

Details

2d0687a083

tim added 1 commit 2026-10-04 15:54:03 +00:00

CI: restore and build MAUI project with win-x64 runtime identifier to ensure runtime packs are restored

Build / build (pull_request) Failing after 37s

Details

8b5dd6f45d

tim added 1 commit 2026-10-04 15:57:04 +00:00

CI: build MAUI target for Android in CI and restore without Windows runtime to avoid missing Mono runtime pack when running locally with act