Rexios

Hey Flutter devs! I'm excited to announce the release of Hive CE v2.11.0-pre, introducing a new interface called IsolatedHive—a safe way to use Hive across multiple isolates.

What's New:

• IsolatedHive Interface: Enables safe Hive usage across isolates by maintaining its own dedicated isolate for database operations. It utilizes an IsolateNameServer behind the scenes to locate the Hive isolate.
• Flutter Integration: Simply call IsolatedHive.initFlutter from hive_ce_flutter to automatically set things up to use Flutter's built-in IsolateNameServer.
• Generated Extensions: The latest hive_ce_generator now provides the same easy-to-use registerAdapters extension on IsolatedHive.

Why Use IsolatedHive?

You might already be using isolates without realizing it! Common Flutter scenarios benefiting from isolate-safe Hive:

• Desktop apps with multiple windows
• Background task handling (flutter_workmanager, background_fetch, etc.)
• Push notification processing

Note: Hive now prominently warns you if it detects unsafe isolate usage.

🎥 Multi-window Demo:

Video: https://files.catbox.moe/stb5gs.mov

Repo: https://github.com/Rexios80/hive_ce_multiwindow

Performance Considerations:

While IsolatedHive adds overhead due to isolate communication and isn't quite as fast as regular Hive CE, it's significantly faster and leaner than Hive v4:

Stability & Testing:

This pre-release is as stable as possible without real-world external testing—your feedback is invaluable!

Check it out, give it a spin, and share your experience:

• hive_ce pre-release
• hive_ce_flutter pre-release
• hive_ce_generator pre-release

Happy coding! 🐝✨

cross-posted from: https://lemm.ee/post/58261438

Hi everyone!

I've just released a new Dart package: isolate_channel. It provides a simple and familiar API for handling communication between Dart isolates, directly inspired by Flutter's MethodChannel and EventChannel APIs used for native plugin communication.

If you've ever found Dart isolate communication cumbersome or unintuitive, isolate_channel streamlines this process, making it feel as straightforward and familiar as working with Flutter plugin channels.

I built this package to prepare for upcoming isolate support in Hive CE, and it made that work a lot easier!

Check it out here: isolate_channel

I'd love your feedback or contributions!

Hi everyone!

I've just released a new Dart package: isolate_channel. It provides a simple and familiar API for handling communication between Dart isolates, directly inspired by Flutter's MethodChannel and EventChannel APIs used for native plugin communication.

If you've ever found Dart isolate communication cumbersome or unintuitive, isolate_channel streamlines this process, making it feel as straightforward and familiar as working with Flutter plugin channels.

I built this package to prepare for upcoming isolate support in Hive CE, and it made that work a lot easier!

Check it out here: isolate_channel

I'd love your feedback or contributions!

Kagi haters are in shambles

Hello Flutter community! I am proud to announce that I have released the largest update to Hive Community Edition yet. Version 2.8.0 adds support for the new GenerateAdapters annotaiton which greatly improves the code generation experience. With the GenerateAdapters annotation, you only specify the classes you want to generate adapters for. No more manually annotating every type and field and keeping track of their IDs.

I also developed a migration tool to help transition from the old annotations. This migration tool makes sure your model classes do not have commmon issues that would result in data integreity issues and then generates the necessary files.

You can see the documentation for the update here: https://pub.dev/packages/hive_ce#store-objects

Hello! I'm the maintainer of Hive Community Edition.

I am proposing to introduce a new annotaiton called @GenerateAdapters. This allows you to generate TypeAdapters for types without explicitly annotating any types or fields. This is much easier to maintian and also allows generating adapters for types outside the current package.

For example:

@GenerateAdapters([
  AdapterSpec<ClassSpec1>(),
  AdapterSpec<ClassSpec2>(),
  AdapterSpec<EnumSpec>(),
])
void _() {}

This will generate type adapters for all the types specified. The main difference between using @GenerateAdapters and explicit annotations is that type IDs and field indexes are determined automatically. This information is then stored in a hive_schema.yaml file which informs future generations which type IDs and field indexes are in use.

My main concern is introducing this feature in a way that allows any future changes to be non-breaking. I believe I have eliminated most of the risk by basing the annotation off of mockito. At the moment there aren't actually any fields in the AdapterSpec class, but adding any in the future will not be a breaking change.

I would really appreciate any feedback the Hive community has on this. If you want to try out the @GenerateAdapters annotation to see how it works in your project, add the following to your pubspec:

dependency_overrides:
  hive_ce:
    git:
      url: https://github.com/IO-Design-Team/hive_ce
      ref: ec6e8d7dfc81a4adb3a9ae9eca0e78bc104116d8
      path: hive
  hive_ce_generator:
    git:
      url: https://github.com/IO-Design-Team/hive_ce
      ref: ec6e8d7dfc81a4adb3a9ae9eca0e78bc104116d8
      path: hive_generator

See the new documentation here

Note that this is a breaking change for the generator, as hive_registrar.g.dart has moved to hive/hive_registrar.g.dart to not clutter the lib folder. I have created a migration guide here

I just released firebase_js_interop which allows you to compose Firebase Cloud Functions in the Dart language. Along with my firebase_rules package it is now possible to create an entire Firebase project with only type-safe Dart code! There are a lot of components missing, but writing the interop code is tedious, not hard. With third-party contributions we should be able to get close to full interop quickly.

The pubstats.dev page keeps track of historical pub.dev data. I just made it so that it can also show the rank of a package on pub.dev based on its popularity score. For example dio is rank 20 right now.

If you haven't seen pubstats.dev before here are some other features:

• Like count and popularity score tracked over time for all packages on pub.dev
• Historical tracking of a lot of package metadata such as version and dependents
• Compare like count and popularity graphs across multiple packages (ex https://beta.pubstats.dev/#/packages/dio,http)
• If you sign in you can set up alerts for package info changes. Very useful for making sure you have maximum pub points! There are only Discord webhook alerts for now since that's what I use personally, but if you'd like to see more options feel free to contribute on GitHub.

As an added bonus, https://beta.pubstats.dev uses the new WASM renderer. Thanks to the Flutter team for helping me make that possible! There is some weirdness with Google OAuth still with WASM (see this issue), but everything else works. If you want to set up Discord notifications you might want to use the stable https://pubstats.dev for now.

Since Hive v2 has been abandoned and v3/v4 are nowhere to be seen I decided to hard fork Hive into Hive Community Edition (hive_ce, hive_ce_fluter, hive_ce_generator). Originally hive_ce was just going to be in maintenance mode to keep up to date with the evolving Flutter/Dart ecosystem (mainly Flutter WASM support right now), but there are some things that bothered me too much to ignore.

First of all... Hive v2 didn't support Sets. Why? I don't know but hive_ce does. Hive boxes natively support the Set type and the generator supports classes with Set fields.

One of the main pain points with TypeAdapters was remembering to register them all. Well forget no longer because hive_ce_generator generates an extension method on Hive to register them all in one go:

import 'package:your_package/hive_registrar.g.dart';

void main() {
  final path = Directory.current.path;
  Hive
    ..init(path)
    ..registerAdapters();
}

I posted about this package before and just got made fun of for the name, but this is a useful update for developers that work on large mono-repos on a daily basis. The puby link command used to require pubspec.lock files to be checked into version control in order to know which dependencies to grab, which most open source mono-repos do not allow. Notably, I work on the flutter/packages repo a lot and dealing with dependency resolution is a pain, but I just released an update to puby to fix this. This involves reusing the dependency resolution code directly from the pub command in order to catalog dependencies rather than relying on lock files. What this means in practice is you can have an empty pub cache, make a clean clone of the flutter/packages repo, and have all dependencies resolved in less than 30 seconds. The puby link command is now almost twice as fast as melos bootstrap and requires zero setup whereas melos likes to complain about your repository structure.

I’m using the iPad app in my Vision Pro and I can log in, but all the feeds just error out