Je travaille sur une application iOS qui fonctionne comme un client léger pour un serveur Bussiness. Il y a beaucoup de demandes envoyées au serveur, beaucoup de données téléchargées.
Je n'utilise aucun cadre de demande de fantaisie, juste asynchrones L'application fonctionne généralement très bien avec WiFi et 3G Certains utilisateurs signalent des déconnectes aléatoires lors de l'utilisation de 3G (aux États-Unis). Toutes les demandes sont okey, mais une fois de temps en temps qu'une demande échoue avec "Impossible de se connecter à l'hôte" (-1004) Erreur.
Cela affecte beaucoup l'expérience de l'utilisateur.
Quelques faits:
Actuellement, la seule solution que je vois est d'essayer d'envoyer la demande si la demande précédente a échoué. Cependant, je voudrais d'abord trouver la cause du problème.
edit Le problème a probablement été causé par l'un de nos routeurs. Les gars-là inspectent toujours le problème. nsurlconnection avec un délégué.
SCNetworkability L'hôte semble être accessible (je connais les limitations de cette API).
3 Réponses :
Je reviendrais l'hypothèse que cela n'affecte que votre demande. Il y a beaucoup de façons que les utilisateurs ne peuvent que les voir les problèmes de votre application, même si le problème est avec leur connexion Internet. Par exemple, peut-être que les autres applications réessayent de manière transparente - les utilisateurs verraient simplement des vitesses de mise à jour plus lentes. Ou peut-être que les connexions abandonnées ne comptent tout simplement pas pour les autres applications.
Avez-vous demandé aux utilisateurs concernés du fournisseur qu'ils utilisent? Si tous utilisent le même réseau mobile, cela indiquerait que c'est un problème avec le réseau plutôt que votre application.
Il me semblerait que la raison de cela est simplement basse à la nature des données cellulaires et de l'accès à Internet. Comme vous le savez peut-être, lorsque vous utilisez une connexion cellulaire, parfois - surtout si vous déménagez, la connexion changera de réseau car elle modifie les tours de diffusion.
Vous mentionnez que vous téléchargez de nombreuses données et à intervalles de près, je supposerais que cela rend votre candidature plus sujette à ce problème, et je n'accepterais pas une seconde que cela ne se produirait pas pour d'autres applications. - Il s'agit de timing.
Bien que cette réponse ne me dise rien de nouveau, c'est probablement la meilleure réponse. Je vais ajouter des tentatives.
Vérification du code de retour d'une demande de réseau suspendue ne réalise rien. Depuis son accroché.
Non seulement cela, mais vous devriez construire un thread, une runloop, un délai d'attente et un décompte de réessayer pour chaque demande de réseau dans votre application pour accomplir ce que vous dites ... pas la bonne solution.
Il n'est pas suspendu car il a échoué avec des erreurs. Lorsque la demande échoue, cela signifie qu'il a abandonné. Si vous souhaitez que les données vous devez envoyer une nouvelle demande. S'il y a toujours une accompagnement accessible, aucune raison de ne pas le refaire. Vous n'avez pas à le faire avec des centaines de threads et un gestionnaire pour chaque demande, si vous vous battez avec de nombreuses demandes, vous pouvez écrire du code pour les centraliser et les gérer au même endroit et vous assurer qu'ils se comportent bien. Je viens de vérifier la portée de la portée, puis de bombarder les demandes, car vous supposez que cela fonctionnera n'est pas une solution très stable.
permet de voir votre code. Je connais que vos tests de l'unité passent et tout sauf au cas;)