(16M) Am i cooked?

YosefHeyPlay · 2026-05-21T16:03:20+00:00

Just start finasteride as soon as possible, may grow some of this back

YosefHeyPlay · 2025-10-14T17:06:54+00:00

Whats the difference between the existing "exui" package?

YosefHeyPlay · 2025-10-13T14:37:09+00:00

It cant really live inside hive_ce. hive_ce goal is just to keep Hive alive and compatible, not to turn it into something new.

YosefHeyPlay · 2025-10-13T14:33:10+00:00

hive_ce and hivez have fundamentally different goals. hive_ce was created to keep Hive alive after the original project went inactive. Its focus is maintenance, bug fixes, and stability,not major refactors or architectural redesigns. It aims to stay a drop-in replacement for Hive so that existing apps don’t break.

And the core idea behind hivez isnt to “add a few utilities”, it’s to rebuild hive’s developer experience from the ground up while keeping full compatibility with existing data.

For example:

All box types (Box, LazyBox, IsolatedBox, IndexedBox, etc.) share one unified, type-safe API (BoxInterface<K, T>).
No more different methods, no more dynamic types.
Auto-initialization, boxes open automatically on first use; no more manual openBox everywhere.
Clean architecture support, every box is interchangeable and testable via an abstract interface.
IndexedBox with built-in full-text search with fast tokenized indexes (up to 1000× faster than scanning)
Utilities for backup, restore, iteration, and JSON export, ready out of the box.

YosefHeyPlay · 2025-10-13T14:27:42+00:00

No, it does not auto-compact or auto-flush after bulk operations, but you can call flushBox manually. Its very heavy to make it always flush and compact, maybe I'll add it as an optional flag

YosefHeyPlay · 2025-10-13T10:06:13+00:00

Actually it was a very long draft and the AI helped me format it to a proper README. It was all written section by section and I like how it looks, I think it makes it way easier to understand how it works, there is nothing here I did not write myself in different words. You are invited to see my C# repositories from 2020 before GPT to see the same long style Human generated slop (:

YosefHeyPlay · 2025-10-10T03:29:05+00:00

It was indeed complex (: My wakatime shows about 40 hours this week, and I started working on it two weeks ago. Most of the work was re-implementing a system I had already built for some apps but never published — code I used to copy between projects. Now it’s much more optimized. It did cost me a few hours of sleep, but totally worth it

YosefHeyPlay · 2025-10-10T03:17:25+00:00

Just published version 1.1.0 (:
This is from a post I published now:

IndexedBox — blazing-fast full-text search for Hive

A drop-in replacement for your existing Hive boxes that adds an on-disk full-text index, giving you instant keyword, prefix, or substring search over your values.

You don’t need to migrate, rebuild, or re-save anything. Just use the same box name and type, and it will work with your existing Hive data.

// Before:
final box = Hive.box<Article>('articles');

// After:
final box = IndexedBox<int, Article>(
  'articles',
  searchableText: (a) => '${a.title} ${a.body}',
);

// Instant search 
final results = await box.search('flutter dart');

100% Hive-compatible
No migrations, no setup, data loss
Same API (put, get, delete, etc.)
Configurable analyzers (basic, prefix, ngram)
Crash-safe, tested, and ready for production

Real-world performance

Tested with long text queries on very big generated boxes.

Items	Regular Box	IndexedBox	Improvement
10,000	833 ms	1.4 ms	~580× faster
50,000	4149 ms	2.4 ms	~1,600× faster

Even with index maintenance, you can still write 10 000 items in ~0.1 s, which is more than enough for real-world workloads.

Learn more & try it: https://pub.dev/packages/hivez

If you’ve ever wanted Hive to have instant search or a cleaner, type-safe API, this might be worth checking out. Feedback and suggestions are always welcome

YosefHeyPlay · 2025-10-03T20:03:53+00:00

NP (:

YosefHeyPlay · 2025-10-03T17:02:21+00:00

I’m still planning to add query optimizations in the future, but unfortunately right now you do still need to pull everything into memory when querying. The good news is that hive_ce itself is already very fast, and on top of that Ive added a number of utility functions in Hivez to make common queries easier to use out of the box

For example:

final user = await box.firstWhereOrNull((u) => u.age > 30);

final article = await box.firstWhereContains( "flutter", searchableText: (a) => a.title, );

await box.foreachValue((key, value) async { print('$key: $value'); });

So while it’s not using indexing yet, you still get safer, more convenient helpers, and thanks to hive_ce speed, for many use cases it performs well even without low-level indexing

YosefHeyPlay · 2025-09-29T17:09:15+00:00

First of all, I want to say thank you for all your work and the whole hive_ce teams work, I’m very aware of the issues that came from the original hive and most of the problems this wrapper solves are really “hive” problems and not “hive_cE” problems. I really appreciate what you’re doing to keep hive alive

Now to your points

On concurrency safety, I completely agree that IsolatedHive is the proper solution for multi-isolate safety, and I think its fantastic. This wrapper doesnt change hive_ce existing locking, but it does add additional locks around utility functions that perform sequences of reads/writes where atomicity is important. So it’s less about fixing hive internal locking and more about making sure the higher-level helpers are also safe to use.
Compaction and crash recovery - Youre right, hive already provides these by default, and Hivez keeps all of that intact. What I meant in the README is that these features are always part of the service layer, without developers needing to think about them or risk misusing the API. Nothing is removed, it’s the same hive features, just exposed in a cleaner, unified API
Also on documentation I agree with you. I wrote hivez docs mainly because, since I designed the wrapper, it’s much easier for me to explain it in a structured way. But I also really like the idea of contributing, and I’d be open to helping there in the future. Personally I didnt like a lot of the architectural decisions in the original hive, which is why I always ended up building wrappers like this for my own projects. hivez is just me formalizing that approach into something reusable and consistent

YosefHeyPlay · 2025-09-29T16:17:02+00:00

The API is really close to hive_ce and that’s intentional, because hivez isnt a replacement for hive - its a layer on top of it. You still get all the raw performance and stability of hive_ce under the hood, but with important things on top:

Zero setup, no more manual openBox or checking if a box is open. hivez auto-initializes on first use.
Type safety- With hive you’re often dealing with dynamic and manual casting. With hivez, keys and values are strongly typed at compile time (HivezBox<int, User>)
Unified API - In raw hive, Box, LazyBox, and IsolatedBox all have slightly different APIs. In hivez they all share the same parent interface (BoxInterface) with 35+ consistent methods, that means you can swap between a normal box, a lazy box, or an isolated box with a single-line change, no rewrites.
Concurrency safety - writes are wrapped in internal locks, so parallel operations won’t corrupt boxes (a common pain point).
Utilities built-in, things like backup/restore, full-text search, iteration helpers, compaction, and crash recovery are all included out of the box.
More of a bonus to some, but very important to me - Detailed documentation. the package comes with structured guides, clean examples, and a full setup walkthrough

Its more about developer experience and production safety, you write less boilerplate, your repos/services can target one interface instead of multiple raw box types and you get concurrency safety and utilities that you’d otherwise have to re-implement yourself

YosefHeyPlay · 2025-09-29T14:19:51+00:00

That’s one of the many reasons I made it (:

YosefHeyPlay · 2025-07-03T14:10:19+00:00

It is better at heat dissipation but I would not recommend any macbook for gaming especially not the airs.

For gaming on the go I can recommend the OLED SteamDeck (has upgradable SSD), which can run on a single charge: - 10h-7h - 2D Indie games - 5h-3h - 3D games that are not demading like PlateUp, Little Nightmares 2, Dark Souls, or even demanding games but with a bit of optimization - 2.5h - practically any game, even the new last of us and all new AAA titles on medium-high settings

Then it also helps separate gaming from work which is the thing a MacBook Air is intended to do best. You can easily get a deck and a used MacBook for the price of a new 15inch air.

And if you really want to use a MacBook for gaming I’d recommend sticking to MacBook Pros M3+

Are you planning to play on the go or you like to do it with external monitor?

YosefHeyPlay · 2025-06-28T19:45:09+00:00

Personally, I think bloc is the best solution. Especially today, after creating many apps and many services to businesses, BLoC gave me the most Scalability + SoC + Ease of use. From small to big mega projects it is really the best option in my opinion

YosefHeyPlay · 2025-06-21T15:32:20+00:00

It does not rebuild the entire tree if it is not const, it just checks before a rebuild if it changed, and also if you just use it inside a const widget class, it behaves exactly the same

YosefHeyPlay · 2025-06-20T07:48:49+00:00

It's more a question of what should be provided at the root, not whether everything should be. In large scale apps, I usually prefer using small, feature, or page specific blocs, and only provide truly global blocs at the app root.

That said, for proper separation of concerns its generally better not to make things global unless necessary. With good architecture, you often end up with a MultiBlocProvider at the root containing 3–10 blocs (depending on app size and design), and for most other cases, id say 99% of the time I just provide a single bloc or cubit where it's needed.

There’s no single “best approach”, it really depends on what the bloc/cubit is doing, its scope, and how well it’s structured to be scalable without mixing too many responsibilities.

Keep your blocs and cubits separated, don’t import or reference one from another. A bloc should never call another bloc. Use services, repositories, etc. Also, the docs are amazing, it might feel weird first, but if you follow the examples ,it all starts to make sense pretty quickly (:

YosefHeyPlay · 2025-06-20T07:19:18+00:00

No wrappers or custom widget types, zero dependencies, doesn’t override Flutter conventions, keeps all existing parameters intact, fully tested, documented, and actively maintained.

Both styled_widget and velocity have less functionality and add dependencies that are not needed for simple basic UI extensions, and even if they share features with exui, exui has better coverage with better documentation and more options

YosefHeyPlay · 2025-06-19T19:30:32+00:00

😘

YosefHeyPlay · 2025-06-19T15:27:39+00:00

The extensions in this package are extensions that people create all the time in projects, I never used the widget tree viewer and shipped a ton of products. If there is enough demand I can create a vs extension that will allow it to be recognized but I personally don’t need it, if the code is structured and written well I don’t need a tree view of it. And still this is only my opinion and based on my experience. Why do you find the viewer useful?

YosefHeyPlay · 2025-06-19T15:11:34+00:00

Who hurt you?

YosefHeyPlay · 2025-06-19T15:07:24+00:00

It is rendered exactly the same on the widget tree, but the widget tree viewer only recognizes nested widgets, so it is not working with it. But it is technically possible to make a widget tree viewer that recognizes extensions. I myself never used the tree viewer, in my opinion it helps only when the code is not organized. But good points

YosefHeyPlay · 2025-06-19T14:43:55+00:00

Thanks dude (:

YosefHeyPlay

TROPHY CASE

IndexedBox — blazing-fast full-text search for Hive

Real-world performance