Does ObjectBox support Kotlin?
While we are currently improving Kotlin support, you can already use it today. Just two things to consider: 1.) Define entities in Java (all other classes can be Kotlin) 2.) Add this line to your build.gradle: android.sourceSets.main.java.srcDirs += 'build/generated/source/objectbox'
How much does ObjectBox db add to my APK size?
Around 1 MB. Because most of this is native code, it does add only little to Android’s method count. Details follow, for uncompressed library sizes see here.
On which platforms does ObjectBox run?
Android (4.0 and above), Linux (64 bit), Windows (32 and 64 bit). We are currently working on macOS and expect a release soon – drop us a line if you are interested. iOS will follow a bit later after 1.0.
Could I use ObjectBox on the desktop/server?
Our current focus is mobile and Android. But technically there is no objection to use ObjectBox on the desktop/server side. For server side usage, keep in mind that ObjectBox is an embedded database though.
How do I rename object properties or classes?
If you only do a rename on the language level, ObjectBox will by default remove the old and add a new entity/property. To do a rename, you must specify the UID.
Can I ship my app with a pre-built database?
Yes. ObjectBox stores all data in a single database file. Thus, you just need to prepare this DB file and copy it to the correct location on the first start of your app (before you touch ObjectBox API). The DB file is called “data.mdb” and is typically located in a sub directory called “objectbox” (or any name you passed to BoxStoreBuilder). On Android the DB file is located inside the app’s files directory inside “objectbox/objectbox/” or, for example “objectbox/yourname” if you assigned the custom name “yourname” using BoxStoreBuilder.
Merge conflict or DbException after concurrent data model modifications
If your team makes concurrent modifications to the data model (e.g. adding/removing entities or properties) it may clash with your changes. Read the meta model docs on how to resolve the conflicts.
DbException after switching git branch (no concurrent data model modifications)
You might get an exception like “DbException DB’s last entity ID 4 is higher than 3 from model” after switching back from a feature branch. This is expected. Let’s say you created a new entity on the feature branch and ran your app on the device. This will update the ObjectBox database on the device. ObjectBox keeps track of entity types internally (stores meta info). Now, when you return to your master branch, ObjectBox notices that new entity from the feature branch is missing. In other words, the database is on a newer version than the code. In general, this is a problematic scenario. For similar reasons, you can not downgrade apps via Google Play in general. It’s like time traveling to the future and going back. Thus, it is advised to clear the database to ensure all “data from the future” is gone. For more background on the topic, consult the meta model docs.
Couldn’t find “libobjectbox.so”
For Android, ObjectBox comes with binaries for “armeabi-v7a” and “arm64-v8a” ABIs. We consider “armeabi” to be outdated and thus do not support it. Check if you have a Gradle config like abiFilters "armeabi", which is causing the problem (e.g. remove it or change it to “armeabi-v7a”).
Version conflict with ‘com.google.code.findbugs:jsr305’
If you are doing Android instrumentation (especially with Espresso), you may get a warning like this:
Error:Conflict with dependency ‘com.google.code.findbugs:jsr305’ in project ‘:app’. Resolved versions for app (3.0.2) and test app (2.0.1) differ. See http://g.co/androidstudio/app-test-app-conflict for details.
You can easily resolve the version conflict adding this Gradle dependency: androidTestCompile 'com.google.code.findbugs:jsr305:3.0.2' (background info).
Incompatible property type
Check the data model migration guide if you get an exception like this:
io.objectbox.exception.DbException: Property […] is not compatible to its previous definition. Check its type.
Beta, 1.0 release, timeline
What does it mean that ObjectBox is beta?
We continue working on ObjectBox and your feedback helps us not only to improve ObjectBox but also prioritize our Roadmap. This also means, there may be breaking changes. This applies to the API and the file format. While we try to avoid chaning the latter, really relevant changes that significantly improve ObjectBox may require us to do so.
I have feedback – where should I put it?
Open an issue in the issue tracker.
When will you ship 1.0 of the Mobile Database?
We don’t have an exact timeline. ObjectBox 1.0 will be released when we feel it is ready. Before we want to make it available to a wider audience, we want to add some features and do some clean up work.
What will change once ObjectBox 1.0 is released?
Starting with 1.0, the API is expected to be much more stable. We will be very considerate with breaking changes. If we need to change the APIs, we usually deprecate the old version and support it for a while to give to time to adjust. If we do changes to the internal file format, we will provide automatic updates. You can keep your database files and probably won’t notice. Also, we will update our license to be more simple and clear.
License / Open Source
The current license is temporary only. We will adjust it shortly for clarifications. If you see issues with the current license, please contact us. We’re sure we can figure it out. We want you to succeed with ObjectBox, and the license should not be an issue.
We strongly believe in Open Source, and so we will be gradually releasing source code to the ObjectBox GitHub repo.
ObjectBox is a free mobile database. We might roll out additional commercial services or products related to ObjectBox in the future. The ObjectBox mobile database will always be free.
Example for commercial services we might offer:
- Implementing a special feature that would benefit your app
- Training and development: to get you started asap, we can come in and help you integrating ObjectBox in your specific context