)

Clarify required flutter channel on CONTRIBUTING guidelines

…ctor_test.dart (#2379)

This is a cleanup identified on this issue: #2308
Using an amazing unused-code tooling
Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code.

This one was a no-brainer -- the variable was clearly replaced by specific counters during the writing of the test and forgotten there:

  int nOnTapDown = 0;
  int nOnLongTapDown = 0;
  int nOnTapUp = 0;
  int nOnTap = 0;
  int nOnTapCancel = 0;

It wasn't even increment and the taps are already thoroughly tested more granularly

This is a cleanup identified on this issue: #2308
Using an amazing unused-code tooling
Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code.

In this case, we have a test helper, which is a public function we expose to help people write better tests.
Which means that the function could be useful, it was just lacking a test -- so I added it.
That being said, if this method is deemed unnecessary for users, I can just remove it instead - lmk.

This is a cleanup identified on this issue: #2308
Using an amazing unused-code tooling
Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code.

In this case, the unused code is in the tests, which likely means it is indeed necessary.
I tried to infer the intent of the author here, and even considered adding the names of the components to the events, but the events are already always per component, so that was meaningless. I also thought it might be a missing toString, that they would wish to show the component name for debugging purposes, but I didn't see any asserts/logs on the component objects themselves (just the events).
So I concluded there is no reason to keep this field, but lmk if anyone disagrees and I can bring it back and add some function to it.

…ample (#2380)

# Description

This is a cleanup identified on this issue:
#2308
Using an amazing unused-code tooling
Now, since Flame is a public API, unused code might not be trivial - it
might just mean untested code.

Since this an example package, it definitely should never have unused
code.
In this case, the constructor wasn't being used, but upon deeper
investigation, that was because this particular event wasn't ever fired
at all.
So I removed it entirely. If this was supposed to be fired somewhere by
the example, please lmk and I can add the missing firing.
But as far as I can see, the event serves no purpose in this example.

## Checklist

- [x] I have followed the [Contributor Guide] when preparing my PR.
- [x] I have updated/added tests for ALL new/updated/fixed
functionality.
- [x] I have updated/added relevant documentation in `docs` and added
dartdoc comments with `///`.
- [x] I have updated/added relevant examples in `examples` or `docs`.

## Breaking Change?

- [ ] Yes, this PR is a breaking change.
- [x] No, this PR is not a breaking change.

<!-- Links -->
[Contributor Guide]:
https://github.com/flame-engine/flame/blob/main/CONTRIBUTING.md
[Conventional Commit]: https://conventionalcommits.org/
[CHANGELOG]:
https://github.com/flame-engine/flame/blob/main/CHANGELOG.md

Co-authored-by: Lukas Klingsbo <me@lukas.fyi>

# Description

This does two things:

## Use double quotes for SDK constraints

Standardize the usage of single or double quotes to specify sdk
constraints across pubspecs
I see no reason this should not be kept consistent
I also see no reason to prefer one over the other, so I searched the
code base and there are 7 instances of single quote vs 32 of double
quotes, so I favored the later

## Update all SDK constraints to 2.18

Let me know if there are any issues with it, but I believe we should
keep this consistent across all packages.
Also there is a pubspec on root which imply all should be on 2.18
anyway.

## Checklist

- [x] I have followed the [Contributor Guide] when preparing my PR.
- [x] I have updated/added tests for ALL new/updated/fixed
functionality.
- [x] I have updated/added relevant documentation in `docs` and added
dartdoc comments with `///`.
- [x] I have updated/added relevant examples in `examples` or `docs`.

## Breaking Change?

- [ ] Yes, this PR is a breaking change.
- [x] No, this PR is not a breaking change.

<!-- Links -->
[Contributor Guide]:
https://github.com/flame-engine/flame/blob/main/CONTRIBUTING.md
[Conventional Commit]: https://conventionalcommits.org/
[CHANGELOG]:
https://github.com/flame-engine/flame/blob/main/CHANGELOG.md

Co-authored-by: Lukas Klingsbo <me@lukas.fyi>

This list was wildly outdated. I could updated it but after
consideration I thought there was no value to list the directory
structure that was already represented in the github view.

Happy to pivot to just updating it though if there are preferences.

…rovider_test.dart (#2381)

This is a cleanup identified on this issue: #2308
Using an amazing unused-code tooling
Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code.

In this case, it is a test file, so there should definitely be no unused code.
However analyzing the unused code revealed to me some intent of testing multiple subsequent state changes (dead -> raise from dead).
I believe such test was missing entirely, so I added it. I think it holds value, but lmk if you disagree I can just delete the test and the method.

The docs for overlays were a bit hard to find so I broke them out to its
own section.
They could need some some updating too with more examples and
instructions.