Flutter desktop native libs

[vaind]

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.dev

Resources:

• Flutter issue tools support for packaging/linking to native libraries
• Flutter issue flutter create --template=plugin-ffi
• Dart SDK issue Define distribution system for native libraries in Pub and/or Flutter

We could use the existing flutter_libs package to include libs for the supported desktop architectures. Those files can be downloaded when publishing, by tool/publish.sh calling objectbox-c download.sh with appropriate arguments.

[vaind]

note: this may require some API changes so at least evaluate before 1.0

[vaind]

We should also keep built app distribution in mind.

[vaind]

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.

[vaind]

MacOS may require further changes, maybe even something lib-users (app developers) need to do:

• https://flutter.dev/docs/development/platform-integration/c-interop#compiled-dynamic-library-macos
• Flutter desktop FFI dlopen fails with file system sandbox blocked open() flutter/flutter#61950

[Tougee]

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

[vaind]

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..

[Tougee]

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)

[greenrobot-team]

@Tougee That issue is probably #217

[Tougee]

Thanks for replying, I've checked for issues before, but I'm not using any antivirus product.

[vaind]

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...

[Tougee]

The target directory is ~/Library/Containers/com.example.flutterApp/Data/Documents/, how to check if an app can write to it?

[vaind]

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');

[greenrobot]

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?

[Tougee]

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.

[vaind]

OK, I've got two updates...

1. the next version we release should have flutter-desktop support without any need to download libraries manually and it will respect the directories where flutter puts libraries so it will also "just work" with all the guides about distributing Flutter desktop apps.
2. I was able to reproduce the macOS issue and indeed it tries to write to the right directory. I've made sure the directory exists so it was only supposed to create files but the issue was still the same, as described by @Tougee. I suspect this has something to do with the app being sandboxed so objectbox-core doesn't have the right permissions to create the database properly. I'll discuss internally and I've noticed there're some docs about this for objectbox-swift: https://swift.objectbox.io/advanced/macos - not sure if any of that applies

[vaind]

the open issue (macOS failing to open a database) is now a separate issue #248