Closed vaind closed 2 years ago
note: this may require some API changes so at least evaluate before 1.0
We should also keep built app distribution in mind.
This article may provide some useful info for the native libs: https://medium.com/flutter-community/build-and-deploy-native-c-libraries-with-flutter-cc7531d590b5 - namely flutter already bundles its .so
libs with the app, so this may be a last resort to plug our lib into that.
MacOS may require further changes, maybe even something lib-users (app developers) need to do:
I've downloaded libobjectbox.dylib
into /usr/local/lib/
, and still got an error
Failed to load dynamic library (dlopen(/usr/local/lib/libobjectbox.dylib, 1): no suitable image found. Did find:
file system sandbox blocked open() of '/usr/local/lib/libobjectbox.dylib'
/usr/local/lib/libobjectbox.dylib: stat() failed with errno=1)
Should I copy the libobjectbox.dylib
into project according this?
https://flutter.dev/docs/development/platform-integration/c-interop#compiled-dynamic-library-macos
Should I copy the
libobjectbox.dylib
into project according this? https://flutter.dev/docs/development/platform-integration/c-interop#compiled-dynamic-library-macos
Yes, for now it seems like you have to do that. Please let me know if that worked for you. In the future, we'd like to get rid of that step for users (i.e. you), but I didn't yet have time to investigate if/how we could do that..
Copy the lib into project seems works good on the link part, but then I meet a new error, and this error also happened when I try to run this demo(https://github.com/objectbox/objectbox-dart/tree/main/objectbox/example/flutter/objectbox_demo)
failed to create store: 10199 Could not open database environment; please check options and file system (1: Operation not permitted)
@Tougee That issue is probably #217
Thanks for replying, I've checked for issues before, but I'm not using any antivirus product.
failed to create store: 10199 Could not open database environment; please check options and file system (1: Operation not permitted)
Can you check what directory does it try to open the database in - it's the directory
argument to Store()
, or if there's none given, than the current-directory/objectbox. Specifically, check the permissions of the directory to see if the app can write to it. Maybe even try writing a dummy file to the same directory manually from the flutter app, using dart:io
...
The target directory is ~/Library/Containers/com.example.flutterApp/Data/Documents/
, how to check if an app can write to it?
try adding something like this just before opening the store, with the same directory you're passing to Store()
:
var file = await File(directory + '/test-file').writeAsString('some content');
ObjectBox really should offer a worry-free way (user perspective) to open a DB using a name. The parent dir of that must default to a platform specific directory that "makes sense"; for iOS & Android this is rather well defined (some user specific data dir). What would be the counter part of these for the desktop OSes?
try adding something like this just before opening the store, with the same directory you're passing to
Store()
:var file = await File(directory + '/test-file').writeAsString('some content');
Write to a file works well, but the Store initialization part still in trouble.
OK, I've got two updates...
the open issue (macOS failing to open a database) is now a separate issue #248
Flutter desktop apps are a thing now so we should think about distributing the native libraries so that developers don't have to get them separately using
install.sh
and can just specify a dependency in the pubspec. At this moment (beginning of 2021), it seems like the only option is still to include .so/.dll files in the package published to pub.devResources:
We could use the existing
flutter_libs
package to include libs for the supported desktop architectures. Those files can be downloaded when publishing, bytool/publish.sh
calling objectbox-cdownload.sh
with appropriate arguments.