[flutter_local_notifications_windows] Windows FFI plugin

[Levi-Lesches]

Update: I went in and simplified the code since yesterday, it's now in a reviewable state. If it would help, I can rebase + commit the first 50 or so commits and start with a cleaner slate.

This is a spin off of #2349, which implements the same logic but with an FFI plugin instead of method channels. I'm happy with it so far, here's the gist:

The C/C++ code

• src/ffi_api.h: a C API between C++ and Dart
• src/plugin.hpp: A C++ class that holds Windows-specific API handles
• src/ffi_api.cpp: C++ code to implement the C API using the C++ class

The Dart code

• a new package, flutter_local_notifications_windows that implements the same functionality as before.
• lib/src/details holds all the platform-specific details
• lib/src/ffi holds basic FFI stuff, like generated bindings and utils
• lib/src/plugin holds the Windows plugin interface, the real FFI implementation, and a stub, because dart:ffi will break web apps (note, the API does reference dart:io but it still compiles on web)

Notes

• Overall, the only thing that changed was how to go from Dart <--> C++. Before, it was all JSON-based message passing, and a big HandleMethodCall function that had to handle every possibility. I'm glad that's gone. Now we have a similar mechanism with Dart <--> C <--> C++ and package:ffigen sets everything up for us.
• It's all backed with compile-time safety as opposed to the runtime failures I was facing with method channels. For example, passing a string now looks like "hello".toNativeString(), but other types require allocating memory manually.
• Functionally, everything is working how it was before, with the method channels

Benefits

• the C++ code is ~150 lines smaller, and went from being one big 250 line file to two 150 line files, one of which can be skimmed as it's just Windows registry config.
• The C++ code no longer uses method channels or any of that associated logic. There's a lot of magic there involving serialization which also comes with a runtime cost. The new code directly passes values and pointers from Dart to C++, eliminating all the message passing. In fact, the new API is inherently synchronous instead of async (not that it matters in this context, since the other platforms are still async).
• The Windows implementation now lives in flutter_local_notifications_windows instead of hijacking the original package and half-sharing some of the original implementations. That means no more platform checks, all the logic can be safely dealt with in a Windows-only context.

Summary of changes

• Windows C/C++ code: +600 lines
• Windows Dart API for customizing notification details): +800 lines
• Windows Dart plugin code, excluding generated code: +300 lines
• Main plugin integrations: < 50 lines
• Example Dart code: +500 lines

That's only ~2,200 additions. the other half GitHub is reporting is automatically generated, like the example's new windows folder.

Important

FFI is a more recent development than method channels. As such, some more advanced FFI features are locked behind some more recent Dart versions. I already had to downgrade package:ffigen from a beta 13.0 to a whopping 7.0, but more pressing is that for C to call a Dart function from another thread (eg, when a notification is pressed), you need to use features from Dart 3.1. The current constraint is only 2.17.

Including this new implementation will force Dart ^3.1.0 on end-users. At this point, 2.17 is two years old, 3.1 is about one year old, and null safety is almost 3.5 years old. Age aside, I also don't believe going from 2.17 to 3.1 is so burdensome, especially since 2.17 is already after null-safety, and the Dart team's official position is that 3.0 is not really a breaking change in practice. In other words, I'm not sure I see a situation where someone is really stuck. They can either upgrade any pre-null-safety code, not upgrade this package further, or fork this package to add null Windows or future updates as needed.

Overall, I'd recommend bumping the SDK version of the front-facing package to 3.1.0 as well to better advertise this, and to benefit from any features, since 2.17 and beyond -- better null promotion, FFI for mobile platforms, class modifiers, macros, and more.

[Levi-Lesches]

was recovering from surgery

Sorry to hear, hope that's going well 🙂

Based on my understanding of the constraints set by ffigen 13.0, this actually needs Flutter 3.19/Dart 3.3 (reference: table under stable at https://docs.flutter.dev/release/archive). Are you able to help resolve this

That's annoying, I checked the changelog and found mention of 3.2 but not 3.3! I changed everything to Dart 3.3 and Flutter 3.19 now.

I could be mistaken but presumably as they're unit tests, the priviledges to be concerned about.

I didn't mock everything out, as I was interested in maintaining tests that the XML does in fact conform to the Windows API. So the unit tests actually do send full XML to the Windows API and try to send notifications. If this doesn't work on the server, I'd still like to keep them, but maybe we'll just run them manually when changing XML code and configure the CI to only run "safe" tests. Speaking of, I added a global retry: 5 to all the tests, given that there are some concurrency issues.

you think you could push an update to have the tests run on Windows? On a related note, is it possible to make updates so that so that the example app is built on Windows as part of the GitHub workflow too? Would require updates to melos.yaml and validate.yml

Hit an annoying issue where "skip these tests on Windows" was actually causing Linux tests to fail. Filed dart-lang/test#2277 to propose to change that, but in the meantime I exclude _windows in the standard unit tests and run it separately as test:unit:windows, only on windows-latest. Needs another workflow approval.

I've also noticed there's a lot of files with changes picked up if I run dart format . from the root of the repo. Are you able to run that (or melos run format) and push the changes?

Done and pushed

---

On another note, I had previously tried to make the Dart package completely separate from Flutter so it can be used in CLI apps. I still believe there is value to that, but when running dart pub lish -n we get an error that is never an issue in practice:

Package validation found the following error:
* pubspec.yaml allows Flutter SDK version 1.9.x, which does not support the flutter.plugin.platforms key.
  Please consider increasing the Flutter SDK requirement to ^1.10.0 (environment.sdk.flutter)

  See https://flutter.dev/docs/development/packages-and-plugins/developing-packages#plugin

Basically, even though having a flutter: section in the Pubspec of a non-Flutter package is harmless, theoretically, someone can use a very early version of Flutter (1.9.x) which would have issues parsing this section. Really, this can never happen because we demand an sdk: ^3.3 and Flutter 1.9 is pre null-safety. So Pub wants us to demand flutter: ^1.10.0, but that means declaring a dependency on Flutter at all, which I was really hoping to avoid. See also this issue.

My recommendation is to run dart pub lish -n first, see if there are any warnings besides the above, and address them first. Then, once this is the only warning left, running dart pub lish --skip-validation to ignore the warning, and preserve CLI ability.

[MaikuB]

I'll take a look and come back to you on these but thought I'd reply in case you missed it since it wasn't brought up in your last message and mention that builds are failing due to the meta version specified

[Levi-Lesches]

Good eye -- fixed

[MaikuB]

Sorry to hear, hope that's going well 🙂

Thanks minor surgery and still bit of discomfort but all good besides that :)

On another note, I had previously tried to make the Dart package completely separate from Flutter so it can be used in CLI apps.

I forgot to ask but is this realistically possible? In the case of the platform interface, this would normally be a transitive dependency. In the case of the Windows plugin, I don't know if you could build a CLI app that shows notifications on the Windows platform? Presumably what you mean is the equivalent of using Visual Studio to create a console app and referencing the Windows APIs to display notifications

My recommendation is to run dart pub lish -n first, see if there are any warnings besides the above, and address them first

This is what I get besides the Flutter one

    error - lib/src/plugin/ffi.dart:122:7 - The named parameter 'data' isn't defined. Try correcting the name to an existing named parameter's name, or defining a named parameter with the name 'data'. - undefined_named_parameter
    error - lib/src/plugin/ffi.dart:200:9 - The named parameter 'data' isn't defined. Try correcting the name to an existing named parameter's name, or defining a named parameter with the name 'data'. - undefined_named_parameter

I've taken a look at the issue you linked and conscious it's been open for a while. I do have a number of thoughts relating to this to and may be missing some additional context and other information so do let me know if I'm missing anything. If issue linked addressed and there are valid cases for CLI apps, I wonder if it'd be better for the "greater good" to go ahead with the Flutter requirement and revisit this. Those who use this plugin would be those looking to build a multiplatform apps. Other aspect of this is if the issue you raised is addressed, then this presumably requires newer version of the Dart SDK. If so, this would cause the Flutter SDK requirement to go even higher and limit the reach even further.

If it's possible to build a Dart CLI app that can show notifications on Windows then this sounds like it one target a very small audience if such an audience even exists. I'm basing this on the assumption that this implies that this is a developer who works on the Windows platform and rather than building a Windows console application, has decided to use Dart. Is this what it would mean? If so, this seems like an odd choice to me. In my experience, companies that build dedicated solutions targeting Windows would employ devs and leverage based on .NET

On a different note, it looks like Windows example is failing to built I'm not sure what's the cause there. However, I'm noticing that the integration tests are failing to run for Android. It seems as though the deprecation warning is being treated as a error but can't reproduce this locally even if I run the integration tests via melos. Given I had raised a PR recently to update one of the workflows and didn't have this issue, I wonder if something got changed that impacted this?

[MaikuB]

It's been a while since I've worked on Windows apps so didn't get to spend much time on it but ran into the following problems relating my previous post

• I had trouble getting a console app to create a notification. I was hoping to copy some of the code for the Windows App SDK samples for showing notifications to achieve this but trouble with having appropriate namespaces and NuGet packages resolve properly
• I tried to create Dart CLI app by creating a separate folder in the cloned repo, reference only the Windows plugin, bootstrap melos etc. Upon trying to run the CLI app, I saw Error: Dart library 'dart:ui' is not available on this platform. as an error message. It looks like this happens as the dependencies the plugin eventually need it and that's only available for apps that depends on Flutter

Based on the above it looks like trying to support CLI apps isn't actually possible, at least not in the current state either

[gryznar]

@Levi-Lesches thank you for your work on this! I highly appreciate Windows support :)

[MaikuB]

@Levi-Lesches no rush and could be that you've been busy. Wanted to ping in case you missed some comments/questions I left. Looks like @autoantwort left a comment on the PR as well

Edit: I also wanted to nudge as I'll be going on holidays in a few weeks time

[Levi-Lesches]

@MaikuB Thanks for the ping, I was kinda going through it with some personal matters.

• I fixed a bug that was causing Windows builds to fail before a certain Windows 11 version (ie, Windows 10)
• Merged master and resolved all merge conflicts
• Ran all tests on my end, including Android, so hopefully the workflows should stay green now
• I reverted the whole Flutter/pure Dart thing. I'm a bit of a purist but that unresolved Pub issue is really annoying

Should be ready to merge now! Note that it depends on _platform_interface: 8.1.0, not 8.0.0, because my branch has changes that are not yet published, so both will need to be published to Pub

[Levi-Lesches]

Okay, @MaikuB I fixed the issue and merged, try now

EDIT: This message got messed up due to DST, I actually sent it later in the thread 🤷‍♂️

[MaikuB]

Thanks @Levi-Lesches. I'll be trying to get the current prerelease out first and then come back to this one. In the interest of time. I may push directly to this fork if there are merge conflicts to resolve afterwards due to this

[MaikuB]

@Levi-Lesches looks like the Windows build tasks failed. You able to see what the issue is?

[Levi-Lesches]

The error is definitely new to me and doesn't occur when I run on my machine. From Googling around, the error FileTracker : error FTK1011: could not create the new file tracking log file seems to be linked to the Windows file length limit...

EDIT 1 Seems this is the first time the CI is running since we added Windows builds to it, so this could be the issue

EDIT 2 @MaikuB Since every workflow run requires your approval, can you add some steps between checkout and build in the windows build jobs to rename the directories to something much shorter? That should fix the issue

[MaikuB]

@Levi-Lesches the approval is need for first-time contributors and in your case, it's due to the PR not having being landed. I won't get to make these changes for a while as I've only time to try to land #2442. If you have time, you may be able to test your proposal by temporarily changing the workflow (e.g. run on push) and see how it fixes the issue. A shame to see the file/path length limit is still a PITA for Windows :(

Edit: looks like this is related to actions/runner#1676. With the issue still being open, I'm not sure if there are solutions available

[Levi-Lesches]

While it's true that the base path is flutter_local_notifications\flutter_local_notifications and cannot be changed, I'm experimenting with changing flutter_local_notifications\example into f\e, which should save some vital characters

---

@MaikuB GitHub isn't handling daylight savings properly on my end, so my comments now are actually being sent upwards in the chat! Anyway, I fixed the issue now, see this which has the fix vs this which does not. Try running it again now. I also fixed the merge conflict

[Levi-Lesches]

@MaikuB So close! Not sure if you missed the CI turning green or want to wait for next week on this, so I'll just drop a reminder. Also not sure if you noticed the chat going wonky during the shift to DST too or if that was just on my end, so I figured I'd leave a message that can actually be at the bottom of the thread this time

[MaikuB]

When I checked after your message, it was still red but the results may have been cached. I still need to retest before merging just in case.

Regarding the timing issue on GitHub, yeah I noticed it but thought it was just me as I've seen a similar issue on Slack that was to do with Chromium browsers but sounds like it was a general problem

[Levi-Lesches]

Thanks, lmk if you need anything else. On the bright side... I guess we know now that the scheduling features on Windows don't throw crazy errors during DST transitions!