EDIT: Any Realm version from 4.0.0-RC1 and above supports natively, so use that instead. RealmList<String> — — — — — — — — — — — — — — — — — — — — I’ll be honest: I really dislike titles that say, “ ”. Especially when the pitfalls of a specific approach aren’t obvious, the opposite is also claimed to be an anti-pattern, and so on. X is an anti-pattern In the case of , you can’t really “support” it at all. I even should have mentioned this already in my . The idea of using to overcome the limitation that (WHICH IS NOT A LIMITATION SINCE 4.0.0) was designed as a hack, back when there was no better solution. Apart from being hideous and not exactly transient to the , it also brings some problems along with it. RealmList<RealmString> Realm schema design article RealmList<RealmString> [RealmList of primitives is not supported](https://github.com/realm/realm-java/issues/575) developer Well, there is a just as hacky solution, but at least you don’t bloat your Realm schema with it :) Problems of RealmList<RealmString> 1.) You need to define a new RealmObject for it You need to create a RealmObject for something that isn’t really meant to be a separate class, an unnecessary wrapper. It also creates a link, which means… 2.) Objects accessed via a link need to be deleted manually Basically if you use in a class, then in order to clear up the objects bound to it, you must iterate the RealmResults first, call on their managed RealmList, and only can you actually delete the objects. Iterating a RealmResults creates a proxy per accessed object, so this can be memory-intensive with large datasets, even though this data should belong directly to the RealmObject, not via a link. RealmList<RealmString> RealmString deleteAllFromRealm() then 3.) Link queries are slower than normal queries Simply put, a link query takes more time than a query on an indexed field. 4.) Any write to the **RealmString** table notifies any other **RealmObject** that has a **link to it (pre-3.0)** (only applies before Realm 3.0) The coarse-grained change listeners assume that your object could have been modified if was modified, which results in unnecessary calls to , which typically calls . RealmString RealmChangeListener adapter.notifyDataSetChanged() Solution: storing RealmList<primitive> as a String Yup, the problem is that people try to store the primitives as a . It doesn’t have to be a List, though. Think about it — you can parcel any List of elements into a String. Even your every-day JSON parser does it all the time. List Parcelling a list to a String is especially easy with a list of primitive values. Look at : this gist from the [RealmList<RealmInteger>, …](https://github.com/realm/realm-java/issues/575#issuecomment-173676006) issue Instead of creating an unnecessary wrapper for the , instead it maps it into a single field, with join separators. For , this can be done with Commons-Lang’s , or Stream API backports. Or manually with . Whichever works. List<String> String Java StringUtils.join() StringBuilder Why does this work well? Since , right? Well with that came in the Realm-Transformer, which converts all direct field access into proxy method calls. Realm 0.88.0, you need to add Realm to the project as a Gradle plugin This is great, because this is what allows us to manually create “computed properties” like as . total this.total = quantity * price; But this allows us to create custom getters/setters, that set the String field even though you give it a List, or returns a List even though the field is a String. Something like this: And if we don’t want to add to the project, you can use this method from Spring Framework: Commons-Lang Or something of that sort. Joining a string shouldn’t be hard. too Conclusion Don’t create unnecessary links. Purge the . RealmList<RealmString> Added note (2017–01–17): But if you still need to separate the elements into their own list, then create a separate RealmObject for it, not a . Here is a concrete example: RealmString This way, you retain a bidirectional link, your TelephoneNumber is independently queryable , allows queries such as , and then use to get whom it belongs to. and sortable find the telephone numbers that contains “___" telephoneNumber.getPerson()
