Hive: Limit the contents of a box

Created on 16 May 2020  Â·  2Comments  Â·  Source: hivedb/hive

So I am using hive on Android. I have an adapter that is basically a class of 3 strings. Since the content of the box is added by the user (like a Contacts app where you add contacts) the user could be saving too many stuff. Since I load my box in main, is there any way I could limit the number of stuff stored inside a box? Like if the user saved 250 contacts and the maximum is 200 then start removing the old 50 contacts.

My second question would be how much is too much?

I tried using lazy boxes but it needs a future builder which messes my grid view builder

question

Most helpful comment

First of all, phones are extremely powerful and something like 200 contacts shouldn't be a problem. In fact, in most phones, memory limitations are very rare to come across today, unless you have some memory leak or deliberately try to exceed the memory limit (or you do something hefty and memory-intensive like video streaming, calculating chess games, training AIs, etc.). Saving contacts (even hundreds, thousands, tens of thousands) shouldn't be a problem.
From a UX perspective, I would also strongly argue against introducing a hard limit in the app. If the user decides to store millions of contacts or uses the content of whole books as contact names, longer startup times are something the user probably expects. The app is degrading gracefully in this case, rather than having a hard limit (which makes users try workarounds like merging unrelated contacts into one with multiple phone numbers).

If huge data volumes regularly slow down the startup of your app, there are things you can do:

  • Use a more performant database solution, like sqflite. This solution runs on the native Android side and uses several SQL-specific performance optimizations. It needs more boilerplate code though. Note that Hive 2.0 will probably resolve your issue, but is still a long time away.
  • If you insist on using Hive, you can still improve (startup) performance.

    • Use a LazyBox. This means, you'll need to await calls, but only the keys are loaded into memory.

    • The more easy approach would be to open the box as late as possible. For example, if the contacts are only visible in a certain part of the app, you could call Hive.openBox(…) only when navigating to that page.

    • Dart is single-threaded by default. You could look into isolates. These are separate thread- or process-like objects that don't share any memory with the main isolate. Isolates can communicate via messages, so you could handle the data processing on a background isolate and only transmit the data immediately needed to the main isolate. Again, this introduces some boilerplate code. Note you still have all entries in memory.

If you still want to limit the number of entries in boxes (btw, I believe there are valid reasons to do that, like limiting the storage for a free version and increasing the limit in a pro version of your app), you should probably write a wrapper class around the box, something like a LimitedBox. When adding data, this box could check how many items it has and remove the oldest item.

Btw: If you implement a LimitedBox and maybe also an extension method for using Hive.limitedBox(…), don't hesitate to publish it as a package on pub.dev for other developers to use. They'll appreciate your effort and you'll be able to more easily reuse your code in future projects.

All 2 comments

First of all, phones are extremely powerful and something like 200 contacts shouldn't be a problem. In fact, in most phones, memory limitations are very rare to come across today, unless you have some memory leak or deliberately try to exceed the memory limit (or you do something hefty and memory-intensive like video streaming, calculating chess games, training AIs, etc.). Saving contacts (even hundreds, thousands, tens of thousands) shouldn't be a problem.
From a UX perspective, I would also strongly argue against introducing a hard limit in the app. If the user decides to store millions of contacts or uses the content of whole books as contact names, longer startup times are something the user probably expects. The app is degrading gracefully in this case, rather than having a hard limit (which makes users try workarounds like merging unrelated contacts into one with multiple phone numbers).

If huge data volumes regularly slow down the startup of your app, there are things you can do:

  • Use a more performant database solution, like sqflite. This solution runs on the native Android side and uses several SQL-specific performance optimizations. It needs more boilerplate code though. Note that Hive 2.0 will probably resolve your issue, but is still a long time away.
  • If you insist on using Hive, you can still improve (startup) performance.

    • Use a LazyBox. This means, you'll need to await calls, but only the keys are loaded into memory.

    • The more easy approach would be to open the box as late as possible. For example, if the contacts are only visible in a certain part of the app, you could call Hive.openBox(…) only when navigating to that page.

    • Dart is single-threaded by default. You could look into isolates. These are separate thread- or process-like objects that don't share any memory with the main isolate. Isolates can communicate via messages, so you could handle the data processing on a background isolate and only transmit the data immediately needed to the main isolate. Again, this introduces some boilerplate code. Note you still have all entries in memory.

If you still want to limit the number of entries in boxes (btw, I believe there are valid reasons to do that, like limiting the storage for a free version and increasing the limit in a pro version of your app), you should probably write a wrapper class around the box, something like a LimitedBox. When adding data, this box could check how many items it has and remove the oldest item.

Btw: If you implement a LimitedBox and maybe also an extension method for using Hive.limitedBox(…), don't hesitate to publish it as a package on pub.dev for other developers to use. They'll appreciate your effort and you'll be able to more easily reuse your code in future projects.

Thanks @marcelgarus for the great response! I think we can close this issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

juandiago picture juandiago  Â·  4Comments

maxim-saplin picture maxim-saplin  Â·  3Comments

ProfileID picture ProfileID  Â·  4Comments

MyoLinOo picture MyoLinOo  Â·  3Comments

sergiyvergun picture sergiyvergun  Â·  4Comments