Vous pouvez rechercher haut et bas pour cela:
dans les données de base, existe-t-il un moyen d'interrompre / arrêter / annuler et exécuter Nsfetchrequest?
Je suis en train de mettre en œuvre une recherche incrémentielle dans une application iPhone, et j'ai essayé tous les moyens de l'optimiser, mais cela ne suffit pas (j'ai 42 000 enregistrements), je dois donc l'exécuter dans une nsopération. Lorsqu'un nouveau personnage est tapé, je dois annuler le précédent fetchrequest, mais [Nsoperation Annuler] ne fait rien.
Une autre approche peut être de déplacer le champ que je recherche dans un autre index interruptible, peut-être en mémoire, ou peut-être une base de données SQLITE3 distincte3, qui semble être interruptible avec SQLITE_Interrupt.
4 Réponses :
Réponse courte - Non, pas directement, désolé.
long réponse - oui mais vous devez faire un peu ou travailler pour le faire
Vous aurez besoin de l'exécuter dans un fil d'arrière-plan (ce qu'il semble être comme si vous faites déjà via Nsoperation)
Dans votre fetch, définissez la limite pour obtenir 20 résultats à la fois et exécutez-la dans une boucle. Chaque fois que traversez la boucle, ajoutez les résultats qu'il accède à un tableau. Chaque fois que la récupération reçoit chaque série de résultats, vérifiez si vous souhaitez annuler la demande.
Ce dernier ne fonctionne pas car pour une requête ordonnée, il faut presque le plus de temps pour obtenir les 20 premiers comme le premier n.
Pour une requête ordonnée, cela ne prendra plus plus longtemps si vous avez un index approprié configuré.
Ma solution consistait à laisser les opérations de requête continuer à fonctionner, mais de vérifier s'ils avaient été annulés avant d'envoyer l'événement pour mettre à jour l'interface utilisateur.
Ce n'est pas parfait car vous pouvez toujours avoir beaucoup d'opérations de requête en cours d'exécution, les résultats pour lesquels ne seront jamais utilisés, mais c'est toujours un peu plus rapide.
J'ai eu le même problème que vous. Pour résoudre, j'utilise un C'est un peu délicat, mais lorsque l'utilisateur tape rapidement 3 lettres rapidement, je ne veux pas envoyer 3 demandes, mais une seule lorsque l'utilisateur Taper fini. J'ai défini un petit délai de 0,5 ou plus. et utilisez ce code: si l'utilisateur est rapide, il annulera les demandes précédentes et Envoyez seulement le dernier. performelector: AfterDelay: Méthode
La réponse directe à votre question est non. Votre meilleure option, avec votre conception actuelle, c'est de les faire en une opération, mais vous avez alors la barrière de filetage pour vous inquiéter et vous ralentir. N'oubliez pas que si vos opérations ne fonctionnent pas sur le thread principal, vous avez besoin d'un Si vous avez déjà les résultats obtenus dans une recherche précédente et que l'utilisateur n'a pas supprimé de caractère, prenez simplement les résultats existants et exécutez votre prédicat contre le Considérez les options suivantes lors de la mise en œuvre d'un champ de recherche:
Selon ce que vous cherchez (et il existe des moyens de renoraliser le magasin de données de base pour améliorer la recherche), vous pouvez précharger un peu dans la mémoire. Même avec des enregistrements 42K si les propriétés de recherche sont suffisamment petites, vous pouvez les charger tout en mémoire.
Il est probable que vous devez tester ce cas d'utilisation de toute façon si l'utilisateur commence à appuyer sur "A".
Quelle partie du NsmanagedObjectContext pour l'opération ou que vous allez courir dans des problèmes de filetage.
Nsarray . Cela affinera davantage la recherche au lieu d'aller au disque à chaque fois. Puisqu'il est en mémoire, il sera extrêmement rapide.
nsfetchrequest est lent? Frapper la base de données SQLITE ou charger les données en mémoire? Basé sur votre réponse, vous pouvez améliorer directement les performances de recherche.
Vous devez également "toucher le disque" si un caractère a été inséré dans le texte de recherche. Par exemple, un utilisateur peut taper "FOOAR" puis le corriger en insérant le caractère manquant, puis la recherche suivante serait "foobar".