[package_info_plus] Desktop Windows

[deakjahn]

May I suggest? Even if it doesn't yet return the real version number, it would be nice to have the federated stub so that it compiles and runs.

[miquelbeltran]

Hi @deakjahn Both MacOS and Windows plugins are already planned for this plugin.

Maybe you want to contribute and create it? 😄

I will close the issue as this is something that we have already planned for.

[deakjahn]

macOS is clearly out of question for me :-) but I can look into the Windows one.

[deakjahn]

@miquelbeltran Well, Windows plugins are a bit different, as I see. There is a prototype at https://github.com/deakjahn/package_info_plus_windows, the example works on its own but doesn't yet work when called from another app. I'm not yet sure the plugin registration works absolutely the same way as on other platforms. Would somebody care to take a look?

[miquelbeltran]

Take a look at https://github.com/fluttercommunity/plus_plugins/tree/main/packages/share_plus_windows and see if you can follow a similar approach, package structure, etc.

As far as I understand, you need to extend this class https://github.com/fluttercommunity/plus_plugins/blob/main/packages/package_info_plus_platform_interface/lib/package_info_platform_interface.dart similar at how it is done here: https://github.com/fluttercommunity/plus_plugins/blob/main/packages/share_plus_windows/lib/share_plus_windows.dart#L10

If you can, fork this repo and try to create the windows plugin package, and you can create a PR even if it doesn't work 100%, then one of us can take a look to see what's missing.

[jpnurmi]

There was also one implementation at https://github.com/fluttercommunity/package_info_plus/pull/7 but it never got transferred to the mono repo?

[miquelbeltran]

well spotted, it should be transferred then

[deakjahn]

Well, I'm already past it, what I linked to is a normal federated plugin according to the usual guidelines and it works with its own bundled example. :-) But if another version already exists, even better, but that link above me gives me a 404.

[jpnurmi]

I pushed https://github.com/fluttercommunity/plus_plugins/tree/feature/package_info_plus_windows

There was an open question about using GetFileVersionInfo() + VerQueryValueA() in the old PR that was forgotten and left behind:

The file version info API the following values for a Flutter counter template app:

• companyName: com.example
• companyShortName: null
• productName: flutter_app
• productShortName: null
• internalName: flutter_app
• productVersion: 1.0.0
• specialBuild: null
• originalFilename: flutter_app.exe
• fileDescription: A new Flutter project.
• fileVersion: 1.0.0

The PackageInfo API consists of:

• appName
• packageName
• version,
• buildNumber

So, the question is... what is what?

[deakjahn]

Can I? This is what I settled on in my attempt:

  return PackageInfoData(
    appName: productName,
    packageName: internalName ?? path.basenameWithoutExtension(moduleNameBuffer.unpackString(moduleNameLength)),
    version: productVersion.split('+').first,
    buildNumber: productVersion.split('+').last,
  );

But build can also be empty if not specified with a +.

[jpnurmi]

@deakjahn I like the idea of splitting the product version if there's a plus in it. Would you like to contribute it as an improvement if we merge #27, or would you prefer your whole implementation over #27?

[deakjahn]

No preference whatsoever, this is not an arms race. :-) I started mine because I didn't know one was already in the works but if it is, let it go through unscathed. I actually removed that linked fork already (although I still have the source). If the suggestion of the version numbers is acceptable, it's all yours to include it.