Support react-native android #16
Comments
7701ba1 Merge pull request #16 from realm/tg-close 883ef12 Add Realm::close() and call it in RealmCache::clear() e9ca54e Merge pull request #12 from realm/tg-core-0.94.4 0823a62 Merge pull request #13 from realm/tg-is-empty 62f59d9 Merge pull request #15 from realm/tg-file-error-path b93e5ce Include the path of the file which actually failed to open in exceptions e1e9cd8 Add ObjectStore::is_empty() 52e7e61 Update for core 0.94.4 271432b Merge pull request #11 from realm/kd-rename-delegate-to-bindingcontext db36ca5 Remove Realm suffix 70e1967 Rename realm delegate in transact_log_handler as well 4973827 Rename RealmDelegate to RealmBindingContext 347145b Merge pull request #8 from realm/mar-migrate-required-to-optional 0b45772 Add a test showing our behavior when migrating from an optional column to a required column. 9f1702a Support migrating required columns to optional, preserving their contents. f5b790c Merge pull request #6 from realm/tg-impl 6dfeaf8 Move things which are not part of the API to an impl directory/namespace 513e483 Merge pull request #4 from realm/tg-realm f646777 Send changes_available() even if autorefresh is enabled 21d32bf Add a bit of documentation for RealmDelegate 95c80c9 Fix error in cleanup after an error during a migration b7936bb Simplify column shifting for removed properties a little a0f1dab Add a Schema class, move lookup by name and internal-consistency checks there b381437 Make Realm::compact() more robust 6133eeb Reduce the scope of a variable 0c111a2 Fix a comment ba278c5 Fix checks for what types of columns can be optional 7de20ea USe more const refs to avoid copies dbac77f Make a bunch of things const 1400450 Remove an unused function 06e0ff8 Share ExternalCommitHelpers between Realm instances for a single path f79dec9 Allow more nullable property types when supported 0eb0bd1 Honor is_nullable when creating columns ea5c475 Refactor schema initialization a bit e4f29fe Move the interprocess notification functionality to the object store b129ebe Shuffle stuff around and clean some things up eeb2ddd Improve array KVO performance a bit c3649fb Skip PK uniqueness checking when first creating a Realm file 0a41c85 Improve performance of realm_requires_update() and make more things const efdfa08 Port some of the KVO support functionality to the object store 65e1eb5 Add the ability to bypass the Realm cache entirely 3f226cf Rework change notifications 045c7b2 Add Realm::get_schema_version() e4377bb Change realm::Schema to a vector rather than a map cae4cf2 Remove property.hpp include from object_schema.hpp 55e6cca Convert RLMRealmConfiguration to a wrapper around Realm::Config 563a837 Use NSDMIs for realm::Property 0ae1bb1 Don't cache dynamic realms in the ObjectStore cache either 25a6734 Eliminate some copies 45890f2 Use NSDMIs for Realm 348f4a7 Reduce s_init_mutex's scope b4f856b Use NSDMIs for Realm::Config and make it moveable a91839b Store a copy of the encryption key 0700428 Merge pull request #3 from realm/al-bugfixes b084335 clear Realm cache between tests cb8364c property copy schema from cached realms 8712c8b fixes for latest object store changes 453e4d8 Fix crash when adding a property to a model without updating the schema version. git-subtree-dir: src/object-store git-subtree-split: 7701ba1
|
Steps added to the first comment |
|
From what I can tell native modules on Android allow to use Java code, not C++ code. This probably means we will need to just define an API in Java that only includes |
|
That's pretty much what I was thinking. The tricky part will be having our c++ objects communicate with react's c++ objects. If everything is just linked together in the ndk level then I could see this working out well. |
|
They did mention a native module written in C++ in the doc https://github.com/facebook/react-native/blob/b86a6e3b44a63e92cf3a7976d2fa26c4bf412df1/ReactAndroid/src/main/java/com/facebook/react/bridge/NativeModule.java
I can't find this class they're mentioning in the Javadoc |
|
@nhachicha that sounds promising. But I also can't find anything remotely similar to that in the code base. Perhaps the comment is stale? Would it be possible to have a Java module that calls into our own c++ code throught jni? If so how do we set this up? I'm not even sure where to begin. |
|
@alazier I'll give it a try once I finish this PR realm/realm-java#1809 |
|
@alazier I created a sample project https://github.com/nhachicha/ReactNativeWithJni to showcase how we can create a native react module that uses JNI. with this approach we can just expose the current Java binding as a JS module (since we're already traversing Java to call C/C++). What could be interesting in terms of performance is to manage to grab the |
Add Realm::close() and call it in RealmCache::clear()
|
Making progress here. All that is left now is chrome debugging and cleanup/proper support from react-native. |
Steps needed to make this happen:
RJSInitializeInContextwith this context to initialize our apis. On iOS we do this in our native module whenever the Bridge gets set. All of the contexts seem to be available in this global variablestatic std::unordered_map<JSContextRef, JSCExecutor*> s_globalContextRefToJSCExecutor;. If we can find a way to access this from our module initializing the context should be straightforward. Alternatively we can change the react-native implementation in a cleaner way in order to expose the JSContext in a cleaner way. Ideally this would be exposed through a jni method on one of the Java objects passed into our native module during initialization. This will require building our own custom version of react-native until we can make a pr against their repo, but this may be the route that we need to follow.The text was updated successfully, but these errors were encountered: