[pigeon] Whether current [PlatformApi] is skip in the generate hostApi

[jackyshan]

When the Api used by Flutter is only implemented on Android or iOS, It needs to skip this unnecessary Api generate on the iOS or Android platform.

In the config of @HostApi, you can use the@iosApiSkip or @androidApiSkip to mark on the method and Skip this Api generation.

• @iosApiSkip represents this API generate skip iOS Platform.
• @androidApiSkip represents this API generate skip Android Platform.

Pre-launch Checklist

• [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• [x] I read and followed the [relevant style guides] and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• [x] I signed the [CLA].
• [x] The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• [x] I listed at least one issue that this PR fixes in the description above.
• [x] I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy], or this PR is [exempt from version changes].
• [x] I updated CHANGELOG.md to add a description of the change, [following repository CHANGELOG style].
• [x] I updated/added relevant documentation (doc comments with ///).
• [x] I added new tests to check the change I am making, or this PR is [test-exempt].
• [x] All existing and new tests are passing.

[stuartmorgan-g]

When the Api used by Flutter is only implemented on Android or iOS, It needs to skip this unnecessary Api generate on the iOS or Android platform.

I'm not clear on why this use case requires any changes at all. If you only want to generate an API for one platform, why isn't it in a platform-specific pigeon definition file?

(In the future, please file issues for proposals first rather than starting with a PR, to get feedback on the problem before implementing an entire solution.)

[jackyshan]

When the Api used by Flutter is only implemented on Android or iOS, It needs to skip this unnecessary Api generate on the iOS or Android platform.

I'm not clear on why this use case requires any changes at all. If you only want to generate an API for one platform, why isn't it in a platform-specific pigeon definition file?

(In the future, please file issues for proposals first rather than starting with a PR, to get feedback on the problem before implementing an entire solution.)

I have written test cases in the files java_generator_test.dart, kotlin_generator_test.dart, objc_generator_test.dart, and swift_generator_test.dart.

This API may only be implemented on iOS or Android, so I have written the implementation in the unit tests for objc, swift, java, and kotlin.

I cannot find a place to submit an issue in this Git repository.

[jackyshan]

When the Api used by Flutter is only implemented on Android or iOS, It needs to skip this unnecessary Api generate on the iOS or Android platform.

I'm not clear on why this use case requires any changes at all. If you only want to generate an API for one platform, why isn't it in a platform-specific pigeon definition file?

(In the future, please file issues for proposals first rather than starting with a PR, to get feedback on the problem before implementing an entire solution.)

On the iOS platform, there is a class called UIFeedbackGenerator that can be used to produce haptic feedback effects such as clicks and pops. However, on the Android platform, the system-level haptic feedback function is already built-in, and no such API is needed to implement it. Therefore, if you want to implement a haptic feedback plugin in Flutter, you only need to use UIFeedbackGenerator on the iOS platform, and on the Android platform, you don't need to implement any additional APIs.

Specifically, in the iOS section of the Flutter plugin, you can use Flutter's platform channel mechanism to call UIFeedbackGenerator to generate haptic feedback effects and return the results to Flutter. However, on the Android platform, as the system has already built-in haptic feedback function, no additional API is needed. In this case, the cross-platform implementation of the Flutter plugin will be relatively simple.

[stuartmorgan-g]

I cannot find a place to submit an issue in this Git repository.

See https://github.com/flutter/packages#issues

Your comments above didn't address my question; you've explained why you want a platform-specific API, which isn't what I asked. My question is why you aren't just using a separate input file for that API, which seems like it accomplishes exactly what you need without any extra complexity in Pigeon.

[jackyshan]

separate input file

I don't quite understand the solution you mentioned about "separate input file", could you please explain it?

[stuartmorgan-g]

Pigeon takes an input file (the --input argument) that defines an API, and generates code from it based on the output configuration you specify. There's no requirement that a project only have one such input file, or that multiple files have the same output languages.

Why not put your cross-platform API in one file that you use to generate output for both Android and iOS, and put your iOS-specific API in a different file that you only generate iOS output from?

[jackyshan]

Pigeon takes an input file (the --input argument) that defines an API, and generates code from it based on the output configuration you specify. There's no requirement that a project only have one such input file, or that multiple files have the same output languages.

Why not put your cross-platform API in one file that you use to generate output for both Android and iOS, and put your iOS-specific API in a different file that you only generate iOS output from?

This is also a solution, thank you

[stuartmorgan-g]

Closing, since based on the discussion above the use case doesn't require new API.