Tu peux le faire si tu fais attention à ne pas utiliser ce Singleton depuis plusieurs threads différents. Si tu as plusieurs Threads, tu dois créer un objet Realm par thread. Mais l’inconvénient des Singletons c’est qu’une fois créés ils ne sont jamais supprimés donc ton objet Realm reste tout le temps en vie même quand tu ne t’en sers plus.
Le risque avec le ! c’est que si pour une raison quelconque ta base de donnée ne veut pas se charger (besoin de migration, config incorrecte, etc.) tu auras un crash.
L’autre problème c’est que si tu as une configuration particulière à passer lors de la création de ton objet Realm, tu vas devoir le gérer à chaque fois.
Une des solutions possibles est de te créer une fonction publique et statique qui crée un objet Realm configuré, en gérant les cas d’erreurs, et qui te le retourne à la fin. Comme ça dès que tu as besoin d’un objet Realm tu appelles cette fonction.
Si tu n’utilises jamais les threads secondaires et que tu préfères ne pas récréer l’objet Realm à chaque fois, cette fonction peut sauvegarder l’objet Realm dans une variable statique et dans ce cas on revient au Singleton
Oui c’est déjà un Singleton mais ça peut être utile de créer ta propre classe de réglages utilisateurs pour centraliser tous les accès au UserDefaults et cacher les clés de type String au monde extérieur.
Cette classe peut utiliser le Singleton pour être plus facilement accessible partout.
Dans le cas de mon application, j’utilise plusieurs threads, mais peut-être que je peux m’arranger pour utiliser un seul thread pour Realm? Même si dans le pire des cas, je peux créer le Singleton sur plusieurs threads, là où j’en ai besoin, mais alors, effectivement, s’il n’est jamais supprimé, c’est peut-être inutile? Qu’est ce que cela implique? De la mémoire vive? Tant que ça, ou c’est négligeable?
Oui, en indiquant:
let realm = try! Realm()
Je voulais dire, le fait d’appeler Realm à chaque fois (et donc d’avoir possiblement plusieurs instances d’accès à Realm en même temps), mais je suis tout à fait d’accord d’éviter le « ! ».
Pour les Users Default, quand tu dis:
centraliser tous les accès au UserDefaults et cacher les clés de type String au monde extérieur
Si j’ai créé une classe static dans laquelle je référence mes clés pour les UserDefaults (pour ne pas me tromper, et me faciliter la vie lors de l’appel), il ne sont pas déjà caché du monde extérieur?
Realm gère très bien le multithreading du moment que tu respectes leurs règles : https://realm.io/docs/swift/latest/#threading
garde ta gestion des threads, si tu l’as fait c’est qu’elle est nécessaire
Je ne pense pas que l’objet Realm consomme beaucoup de mémoire à priori.
Si mais c’est souvent plus sympa de faire une classe singleton qui masque le UserDefaults avec des méthodes du genre getScore() et setScore(Int) accessibles depuis l’extérieur. Ca permet d’oublier complètement la notion de clé dans tes viewControllers.