Skip to content

[path_provider] Convert iOS/macOS to FFI package #9762

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
## NEXT
## 2.5.0
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be a breaking change? Developers who are importing the "path_provider_foundation" module directly will get a build failure since it's not longer available. Here's an example I found:

https://github.com/MixinNetwork/flutter-app/blob/1a0fd1691c3c5fd9a4d86097d73efeb438cd9ca5/macos/Runner/AppDelegate.swift#L5

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't generally consider native code changes to be breaking changes for the plugin unless the native code is explicitly intended for direct native use (e.g., this file).

I can't think of a good reason to directly import this native package. Notably, that code... doesn't appear to make sense? The import is there to create an instance of the plugin that is never used and never wired up to anything. Also, even if we considered this a breaking change for path_provider_foundation, we wouldn't consider it a breaking change for path_provider, and that app is not directly relying on path_provider_foundation so would be broken anyway.

Ultimately, there's a large grey area of things that can break unexpected use cases, but that we don't consider breaking (e.g., adding a parameter to a method of a Dart class that's not intended to be subclassed). I would definitely include this change in that area. We have not considered it breaking in the past to change the name of the plugin class, which is very similar.


* Replaces Flutter-plugin-based implementation with direct FFI calls to
Foundation.
* Updates minimum supported SDK version to Flutter 3.29/Dart 3.7.

## 2.4.2
Expand Down
18 changes: 18 additions & 0 deletions packages/path_provider/path_provider_foundation/CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
# Contributing

## `ffigen`

This package uses [ffigen](https://pub.dev/packages/ffigen) to call Foundation
methods, rather than using the standard Flutter plugin structure. To add new
functionality to the FFI interface, update `ffigen_config.yaml`, then run:

```bash
dart run ffigen --config ffigen_config.yaml
```

### Configuration philosophy

This package intentionally uses very strict filtering rules to include only the
necessary methods and functions. This is partially to keep the package small,
but mostly to avoid unnecessarily generating anything that requires native code
helpers, which would require setting up a native compilation step.

This file was deleted.

This file was deleted.

This file was deleted.

This file was deleted.

This file was deleted.

Loading