Comment gérer l'application en cas de rupture de connexion entre un appel de service Web

Question

Dans plusieurs entretiens, j'ai été interrogé sur le traitement de la connexion, les appels de service Web, les réponses du serveur et tous. Même maintenant, je ne suis pas clair sur beaucoup de choses. Pourriez-vous m'aider s'il vous plaît à avoir une meilleure idée sur les scénarios suivants?

1. Quel est l'avantage d'utiliser NSURLSessionDataTask au lieu de NSURLConnection -J'ai une idée, comme la perte de données ne se produira pas, même si les ruptures de connexion pour NSURLSessionDataTask mais pas pour le latter.But comment cela fonctionne?

2. Si les ruptures de connexion après l'envoi de la requête à un serveur ou lors de la connexion au serveur, Comment peut-on gérer le code à notre fin en cas de NSURLConnection et NSURLSessionDataTask? Idée -Ma est d'utiliser des classes d'accessibilité et de vérifier quand il devient en ligne.

3. Les données que nous envoyons ont été mises à jour côté serveur. Mais nous n'obtenons pas la réponse du serveur. Que pouvons-nous faire à nos côtés pour gérer cette situation? - Incrémenter timeOutInterval est la seule chose que nous pouvons faire?

S'il vous plaît aidez-moi avec ces scénarios. Merci beaucoup d'avance!!

Answer 1

C'est vraiment plusieurs questions, mais j'essaierai d'y répondre brièvement.

1. La plupart manipulation d'échec est le même entre NSURLConnection et NSURLSession. Les principaux avantages de ce dernier sont la prise en charge des téléchargements en arrière-plan et l'annulation de groupes de demandes connexes. Cela dit, si vous faites un gros téléchargement qui pourrait échouer, NSURLSession fournit des tâches de téléchargement qui vous permettent de reprendre le téléchargement si votre connexion réseau échoue, similaire à ce que faisait NSURLDownload sur OS X (jamais disponible sur iOS). Cela ne facilite que le téléchargement de fichiers volumineux, mais pas pour les gros téléchargements (qui nécessitent une reprise importante du côté serveur) ou d'autres demandes.

2. Votre intuition est correcte. En cas d'échec d'une connexion, créez un objet d'accessibilité surveillant ce nom d'hôte particulier pour savoir quand il serait opportun d'essayer à nouveau la requête. Ensuite, essayez à nouveau la demande.

   Vous pouvez également afficher une sorte d'interface utilisateur pour indiquer que vous n'avez pas de connexion Internet. (Par conseil, je veux dire quelque chose que l'utilisateur n'a pas à cliquer et qui n'a pas d'impact sur l'utilisation hors ligne de l'application, regardez l'application Facebook pour un bon exemple.)

3. identificateur unique lorsque vous effectuez la demande, et stockez-le sur le serveur avec la réponse du serveur jusqu'à ce que le client accuse réception de la réponse (ou la purge de toute façon après un nombre raisonnable de jours). Lorsque le téléchargement est terminé, le serveur vous renvoie sa réponse s'il le peut.

   En cas de problème, le client demande au serveur de renvoyer la réponse associée à cet identificateur unique. Une fois que votre client a les données, il accuse réception et le serveur supprime la réponse. Si vous demandez au serveur la réponse et qu'il n'en a pas, le téléchargement ne s'est pas vraiment terminé. Avec un peu de travail supplémentaire, cette approche peut permettre de prendre en charge des envois de longue durée de manière plus fiable.Si un téléchargement échoue, demandez au serveur combien de données il a reçu pour cet identifiant, puis dites au serveur que vous allez télécharger de nouvelles données à partir de l'octet suivant. Du côté serveur, remplacez les anciennes données en commençant par cet octet (juste au cas où des données étaient encore en cours d'écriture lorsque vous demandiez la longueur).

Espérons que ça aide.