Skip to content
This repository has been archived by the owner on Feb 22, 2023. It is now read-only.

[path_provider] Add Windows support #2818

Merged
merged 40 commits into from Sep 18, 2020

Conversation

timsneath
Copy link
Contributor

@timsneath timsneath commented Jun 5, 2020

Description

Implements path provider for Windows

Related Issues

Fixes flutter/flutter#41715.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
  • All existing and new tests are passing.
  • I updated/added relevant documentation (doc comments with ///).
  • The analyzer (flutter analyze) does not report any problems on my PR.
  • I read and followed the Flutter Style Guide.
  • The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
  • I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
  • I updated CHANGELOG.md to add a description of the change.
  • I signed the CLA.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

  • Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
  • No, this is not a breaking change.

Copy link
Contributor

@stuartmorgan stuartmorgan left a comment

Choose a reason for hiding this comment

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

Sorry for the review delay. I'm still trying to get Windows CI set up.

packages/path_provider/path_provider/pubspec.yaml Outdated Show resolved Hide resolved
packages/path_provider/path_provider_windows/README.md Outdated Show resolved Hide resolved
packages/path_provider/path_provider_windows/README.md Outdated Show resolved Hide resolved
/// On Windows, this the path specified by the TMP environment variable, or
/// the TEMP environment variable, or the USERPROFILE environment variable,
/// or the Windows directory, in order of preference. Windows does not
/// guarantee that the path exists or is writeable to.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should handle existence here; path_provider users should be shielded from the platform-specific details, and they are unlikey to come read these docs. Returning a temp path that doesn't exist seems like an unnecessary foot-gun for developers.

@technolion
Copy link
Contributor

Could you please add support for getDownloadsPath as suggested in this PR?
google/flutter-desktop-embedding#765

Copy link
Contributor

@stuartmorgan stuartmorgan left a comment

Choose a reason for hiding this comment

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

A couple more notes based on having recently been doing Windows plugin work.

It looks like we could have CI online soon (maybe next week?), at which point this will be unblocked. Will you have time to iterate on this PR soon? If not, should we do a handoff? I'd like to get it in ASAP after the CI is online so that we have something exercising the CI to prevent it from breaking without us noticing.

/// files.
@override
Future<String> getApplicationSupportPath() =>
getPath(WindowsKnownFolder.ProgramData);
Copy link
Contributor

Choose a reason for hiding this comment

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

There's a mismatch here between what the Windows API gives and what a path_provider user is likely to expect; on mobile these folders are in the app sandbox, so it's reasonable to just create files in the directory returned by getApplicationSupportPath; in a Win32 app (unless running in a compatibility hypervisor, IIRC) it's the top level folder that all applications share.

For the FDE plugin what I did is append a directory using the executable name (from GetModuleFileName). I think we need do that (or something like it if there's a better value we have access to) there.

(We may want to add an API to path_provider_windows that allows people to manually set it to a value of their choosing, overriding the default of exe name.)

Choose a reason for hiding this comment

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

Wouldn't it make sense to place all app data in the userprofile/AppData/local/AppName as default?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I missed that difference from FDE. I was using RoamingAppData; that (or LocalAppData) seems like the right location for application support data. ProgramData sounds like it's not user-specific.

Copy link
Contributor

Choose a reason for hiding this comment

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

@timsneath I've updated this to match FDE (using RoamingAppData, and appending the exe name), with a placeholder for the exe name until win32 is updated to GetModuleFileName or GetCurrentProcess. Let me know if you have any concerns about using that path.

@timsneath
Copy link
Contributor Author

Will you have time to iterate on this PR soon? If not, should we do a handoff? I'd like to get it in ASAP after the CI is online so that we have something exercising the CI to prevent it from breaking without us noticing.

Thanks for the prod (and for the pull request review comments). It's time I picked this bit up again (got distracted with Windows Runtime API interop improvements). I'll take a look over this Labor Day weekend and see if I can patch this into good shape.

Copy link
Contributor

@stuartmorgan stuartmorgan left a comment

Choose a reason for hiding this comment

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

(Marking as "reviewed" so it doesn't continue to indicate that the PR is waiting for changes I requested.)

@stuartmorgan
Copy link
Contributor

@csells @cyanglaz Since I made non-trivial changes to the PR, I'll wait for one of you to review it before landing.

Copy link
Contributor

@csells csells left a comment

Choose a reason for hiding this comment

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

all of it looks good except I'm not sure about the need for a Windows-specific sample

@@ -0,0 +1,8 @@
# path_provider_windows_example
Copy link
Contributor

Choose a reason for hiding this comment

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

do we need a separate sample for Windows? won't the normal path_provider sample do?

Copy link
Contributor

Choose a reason for hiding this comment

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

There's an open question in the longer term about how to best structure the tests and examples for federated plugins. The plugin repo tooling expects them though, and it does have value in the general case:

  • It's a self-contained way to build and test the plugin, which is convenient for plugin development.
  • It can test platform-specific APIs (which we don't currently have, but could in the future).

So long term, TBD, short term, this is the standard practice we've been following.

@stuartmorgan
Copy link
Contributor

Per #2988 (comment) the application support path approach here isn't correct. I'll need to update the template to add VERSIONINFO, and read that here.

@stuartmorgan
Copy link
Contributor

@timsneath It looks like we'll need GetFileVersionInfo, GetFileVersionInfoSize, and VerQueryValue in win32 now as well, to read this information.

@timsneath
Copy link
Contributor Author

Have a PR ready that will add these APIs, but I need to add some tests before I merge and publish. I'll do that by EOD. dart-windows/win32#103

@timsneath
Copy link
Contributor Author

timsneath commented Sep 17, 2020

OK, version APIs are all in win32 v1.7.1 (https://timsneath.github.io/win32/topics/version-topic.html)

Follows the full convention of company-name\app-name\ as the
subdirectory, using the VERSIONINFO resource if there.
@stuartmorgan
Copy link
Contributor

@csells Please re-review for the new AppData subdirectory logic.

@stuartmorgan
Copy link
Contributor

I just wasn't aware of it. Updated.

I'm going to have to revert this; it appear that it makes the flutter/plugins repo tooling think the tests have failed:

RUNNING path_provider/path_provider_windows tests...
Running "flutter pub get" in path_provider_windows...               1.4s
No tests ran.
SKIPPING path_provider/path_provider_windows/example - no test subdirectory



Tests for the following packages are failing (see above):
 * path_provider/path_provider_windows

This wasn't happening with the skip option 🤷

@stuartmorgan stuartmorgan merged commit 1685a28 into flutter:master Sep 18, 2020
@timsneath timsneath deleted the path_provider_windows branch September 18, 2020 14:12
nabil6391 added a commit to nabil6391/plugins that referenced this pull request Sep 18, 2020
@stuartmorgan stuartmorgan removed the WIP label Sep 18, 2020
danielroek pushed a commit to Baseflow/flutter-plugins that referenced this pull request Oct 1, 2020
Implements path_provider for Windows, adding path_provider_windows and endorsing it in path_provider.
jorgefspereira pushed a commit to jorgefspereira/plugins_flutter that referenced this pull request Oct 10, 2020
Implements path_provider for Windows, adding path_provider_windows and endorsing it in path_provider.
FlutterSu pushed a commit to FlutterSu/flutter-plugins that referenced this pull request Nov 20, 2020
Implements path_provider for Windows, adding path_provider_windows and endorsing it in path_provider.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
9 participants