GitLab

* Prevent adding events to closed stream controller

chore: Use `unawaited` instead of ignoring the lint

fix: Hive iOS init

- removes duplicate init on iOS breaking directory structure
Signed-off-by: The one with the braid <the-one@with-the-braid.cf>

fix: Created path using collection names

fix: don't mark registry as final

Makes 5250d345

 work also with
collections.
Co-authored-by: Nicolas Werner <n.werner@famedly.com>

Found this typo a bit confusing,so I decided to request a fix

- remove final marker from registry
- remove unwanted visible for testing
Signed-off-by: The one with the braid <braid@famedly.com>

Using `unawaited` provides more context about the purpose of not
awaiting a future and it has no effects. In this commit, I simply
deleted the "ignore lint" comment and wrapped the `remove` function in
`unawaited`.

Following is the implementation of `unawaited` (from "dart:async" package):
```dart
/// Explicitly ignores a future.
///
/// Not all futures need to be awaited.
/// The Dart linter has an optional ["unawaited futures" lint](https://dart-lang.github.io/linter/lints/unawaited_futures.html)
/// which enforces that potential futures
/// (expressions with a static type of [Future] or `Future?`)
/// in asynchronous functions are handled *somehow*.
/// If a particular future value doesn't need to be awaited,
/// you can call `unawaited(...)` with it, which will avoid the lint,
/// simply because the expression no longer has type [Future].
/// Using `unawaited` has no other effect.
/// You should use `unawaited` to convey the *intention* of
/// deliberately not waiting for the future.
///
/// If the future completes with an error,
/// it was likely a mistake to not await it.
/// That error will still occur and will be considered unhandled
/// unless the same future is awaited (or otherwise handled) elsewhere too.
/// Because of that, `unawaited` should only be used for futures that
/// are *expected* to complete with a value.
/// You can use [FutureExtensions.ignore] if you also don't want to know
/// about errors from this future.
@Since("2.15")
void unawaited(Future<void>? future) {}
```

This is somewhat of a workaround for an iOS issue we ran into. We use
hive as the database for a chat application. To be able to show
notifications when the app is in the background we use a Notification
Service Extension and give the NSE access to the database, so that it
can read the room names and such from the database. (We implemented a
barebones hive reader in Swift for that.)

Since the database is only opened read only while the app is suspended
and we only read data from it and immediately close it again, we don't
really have any concurrency issues. However, iOS unconditionally kills
your application if it has any lockfiles open in a directory, that
another process could access. Since we share a container with the NSE,
our app gets killed any time it is backgrounded. There might be other
ways to solve this, but since we already make sure the database can only
be written to by one process, I think disabling the locks is the best
option, since they are not needed in our case. Another option would be
to lock more granularly or prepend an SQLite file header, but those
seem like worse options to me.

For reference, here is a an issue about how SQLCipher ran into that
issue: https://github.com/sqlcipher/sqlcipher/issues/255

* fix: Apply analyzer 5.0.0 or higher

* fix: Change `ClassElement` to `InterfaceElement`

* Update .github/workflows/test.yml
Co-authored-by: Misir <misir.ceferov@gmail.com>

* feat: Update hive_generator version (2.0.0)
Co-authored-by: Misir <misir.ceferov@gmail.com>

fix: missing TupleBoxKey for opening boxes