Skip to content

feat(windows): add Windows support backed by PlayFab#230

Open
RealMeeseeks wants to merge 5 commits into
developfrom
feat/windows-playfab-support
Open

feat(windows): add Windows support backed by PlayFab#230
RealMeeseeks wants to merge 5 commits into
developfrom
feat/windows-playfab-support

Conversation

@RealMeeseeks

Copy link
Copy Markdown
Collaborator

Adds Windows support to games_services via a pure-Dart implementation backed by the Microsoft PlayFab REST API (registered for the windows platform via dartPluginClass).

What

  • GamesServicesPlayFab implementing the full platform interface:
    • Auth: LoginWithCustomID with a device GUID persisted in shared_preferences
    • Leaderboards: player statistics (UpdatePlayerStatistics, GetLeaderboard/AroundPlayer/Friend)
    • Achievements: Title Data definitions + User Data progress
    • Saved games: entity files (JSON envelope w/ base64 cover image) + entity-object index
    • Native-UI / Apple-Google-only methods return null
    • Non-breaking GamesServices.initialize(playFabTitleId: ...) (no-op elsewhere) + Device.isPlatformWindows
    • Example windows runner; docs (docs/windows_playfab.md + README); versions -> 5.2.0
    • Unit tests with mocked http.Client for the REST mappings

Verification

  • dart analyze clean; 12 unit tests pass
    • The Windows app build was NOT run (dev machine is macOS). CI must run flutter build windows, and a real end-to-end test needs a live PlayFab title (see docs for Game Manager setup).

Mr.Meeseeks and others added 4 commits June 5, 2026 19:06
Google's Play Games Services quality checklist (item 6.1) requires a
cover image when saving a game. The saveGame flow previously did not
expose any way to set one.

Add optional `coverImage` (image bytes), `description` and `playedTime`
parameters to `SaveGame.saveGame`, threaded through the federated
platform interface and the method channel. On Android these are applied
via `SnapshotMetadataChange.Builder` (`setCoverImage` decodes the bytes
to a Bitmap, plus `setDescription` / `setPlayedTimeMillis`). They are
ignored on iOS/macOS (Game Center has no snapshot metadata equivalent).

All new parameters are optional, so existing callers are unaffected.
Also fixes the previous Android bug where the unique name was passed as
the snapshot description; the description is now only set when provided.

Bumps both packages to 5.1.0 and updates the example app and
docs/save_load_game.md.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Windows has no native equivalent of Game Center or Google Play Games, so
this adds a pure-Dart federated implementation backed by the Microsoft
PlayFab REST API, registered for the windows platform via dartPluginClass.

- New GamesServicesPlayFab implementation (auth via LoginWithCustomID with a
  persisted device GUID, leaderboards via player statistics, achievements via
  Title Data definitions + User Data progress, saved games via entity files).
- Add non-breaking GamesServices/GameAuth.initialize(playFabTitleId: ...) and
  a no-op default on the platform interface; add Device.isPlatformWindows.
- Add http + shared_preferences deps and the windows runner to the example.
- Unit tests (mocked http.Client) covering the REST mappings.
- Docs (docs/windows_playfab.md + README), CHANGELOGs, versions -> 5.2.0.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The PR Checks workflow installed Flutter 3.7.3, which cannot satisfy the
packages' `sdk: ^3.12.0` / `flutter: ">=3.44.0"` constraints, so
`flutter pub get` failed before Danger ran (the step exited 1 with no
Danger comment posted).

- Install a compatible Flutter (3.44.1 stable) via subosito/flutter-action,
  and bump actions/checkout to v4.
- Run `flutter analyze` inside each package instead of the repo root (which
  has no pubspec.yaml and always errored).
- Resolve example dependencies too.
- Soften the >1000-line PR size rule from fail to warn; a new-platform
  integration legitimately exceeds it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Danger step used a custom `DANGER_GITHUB_API_TOKEN` repo secret that
GitHub rejected as "Bad credentials" (401), so Danger could not fetch the
pull request and the step failed.

Switch to the run's built-in `secrets.GITHUB_TOKEN` and grant the job
`pull-requests: write` / `contents: read`. This removes the dependency on a
manually-maintained PAT secret.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions

github-actions Bot commented Jun 10, 2026

Copy link
Copy Markdown
Warnings
⚠️ This pull request is large: it changes 2890 lines (soft limit 1000). Consider splitting it into smaller pull requests when possible.

Generated by 🚫 dangerJS against 043d6b4

`flutter analyze` (Dart 3.12.1 lints) reported 4 issues:

- prefer_initializing_formals in GamesServicesPlayFab: renamed the injected
  constructor parameter to `playFabClient` (a private field can't be a named
  initializing formal).
- use_null_aware_elements (x3) in PlayFabClient: replaced
  `if (x != null) "Key": x` map entries with the null-aware `"Key": ?x` form
  in getPlayerStatistics and updateUserData.

Also silence the pre-existing monorepo `invalid_dependency` (path dependency)
warning via analysis_options, and drop a now-redundant test import/cast.
Verified clean with `flutter analyze` on both packages and all tests passing
under Flutter 3.44.1.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

@theLee3 theLee3 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am in the process of reviewing the full addition as well as setting up PlayFab to test. However, I have a couple of initial thoughts after a cursory reading of the changes.

As the package is already structured as a federated plugin, would it not be better to add the PlayFab functionality under an endorsed federated games_services_windows package? This would remove the Windows specific implementation from the games_services package where devs would have unnecessary knowledge of the public class and methods used, as well as removing the base package's dependency on http and shared_preferences.

Also, is it possible to be less opinionated on the ID generation and use of shared_preferences? Is this something that we can leave to the developer and simply provide a means of using the tokens to communicate with PlayFab? This would allow cross device account usage as well as the use of different auth services.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants