These are some things we discovered during a POC. Maybe ‘everyone knows, nobody tells?’
Any corrections and suggestions are welcome.
app.CurrentUser is persisted on disk. No need to use LoginAsync after a single initial login. Use sync Realm with Realm.GetInstance(config) where config is SyncConfiguration(partitionKey, user) for flawless data sync, offline-first.
In .Net at least, all models that inherit from RealmObject should be located in the same project (assembly) where data access happens. If not your models will not be known to Realm.
Cannot use RealmObjects as models to transmit data over HTTP. You need to create POCOs and copy over data from RealmObject-derived models
Always have one global Realm and configuration. Use Realm for read/write requests with GetInstance(config) and dispose. The global Realm ensures that changes upstream at Atlas are listened to and local storage is updated. In the absence of a global Realm, models are only updated when ‘read’.
Hey, thank you so much for this feedback. I’ll try to address these points one by one:
This is definitely something we need to document - I’ll ping the docs team to get it included.
You don’t need to have all RealmObject inheritors in the same assembly but you do need to reference something from those assemblies to ensure that the assembly is loaded, otherwise Realm will not discover them the first time it’s opened.
What is the issue you were facing when using RealmObject inheritors? If using Newtonsoft.Json for serializing your objects, you should probably use MemberSerialization.OptIn to ensure you don’t get any of the base members in your json representation (see SO answer).
That is somewhat usage-specific - for apps that have a UI (and main thread), we recommend keeping a Realm on the main thread open and use that one to drive the UI and opening and disposing Realms for each unit of work that needs to be done on a background thread. But we should be a bit more explicit about it and I’ll see where we can add it to the documentation.
Again, thanks for the feedback here - even if some of this information exists spread over multiple venues, we should definitely try to consolidate it and make it more discoverable so that new users have an easier time getting started and don’t run into weird behavior.
You don’t need to have all RealmObject inheritors in the same assembly but you do need to reference something from those assemblies to ensure that the assembly is loaded, otherwise Realm will not discover them the first time it’s opened.
This has not been our experience. The models were declared (when defined in another assembly) and we received the same error. There is fody weaver in the mix and I think this is an issue with transitive dependencies. Realm isn’t able to reach the RealmObject related types in another assembly through the referenced project.
What is the issue you were facing when using RealmObject inheritors?
We will try out the OpIn attribute. We were trying to use the RealmObject derived model in a HttpResponseMessage and got errors. Will post the exact exception later.
That is somewhat usage-specific
All usage, at least how MongoDB Sync has been advertised and to which we were attracted to is Offline-first. IS there any other way Realm can be used to achieve this Offline-first functionality other than having a Realm open on the main thread? I wager, no.
This is why I think the documentation needs to reflect this key fact so developers are aware.