Je construis une application mobile dans VB.NET (framework compact), et je me demande quelle est la meilleure façon d'aborder les interactions hors ligne potentielles sur le périphérique. Fondamentalement, les appareils ont cellulaire et 802.11, mais peuvent encore être hors ligne (où il y a une mauvaise réception, etc). Un pilote va scanner les boîtes à la sortie de son camion et je souhaite mettre à jour le nouvel emplacement - immédiatement s'il y a un signal réseau, ou mis en file d'attente s'il est hors ligne et traité plus tard. Cela m'a cependant fait réfléchir à la façon de gérer le mode hors connexion en général. Est-ce que je cache le plus de données possible sur le périphérique pour que je puisse l'utiliser s'il est hors ligne? Essentiellement, chaque périphérique aurait une copie des données de production (pertinentes) sur celui-ci? Ou est-il préférable de désactiver certaines fonctionnalités quand il est hors ligne, afin d'éviter le mal de tête de la synchronisation plus tard? Je sais que c'est une question assez spécifique qui dépend de mon application, mais je suis curieux de voir si d'autres ont pris cette route. .Application d'appareil mobile .NET CF - meilleure méthodologie pour gérer le potentiel hors connexion?
Répondre
Nous ne pouvons pas vous donner une réponse définitive parce qu'il n'y a pas de réponse « droit » qui correspond à tous les scénarios d'utilisation. Par exemple, si vous utilisez SQL Server sur le backend et SQL CE localement, vous pouvez toujours configurer la réplication de fusion et laisser le moteur de données gérer tout cela pour vous. C'est plutôt propre. L'utilisation du bloc d'application hors ligne peut le résoudre. L'utilisation du stockage et du transfert peut être une option.
Vous pouvez stocker localement puis rouler votre propre synchronisation avec une connexion directe, service web service WCF utilisé lors de la détection d'un réseau. Vous pouvez utiliser MSMQ pour la livraison.
Ce que vous devez penser à est pas ce que la « bonne » est, mais comment votre mise en œuvre aura une incidence sur la facilité d'utilisation de l'application. Si vous désactivez les fonctionnalités en raison d'un manque de connectivité, l'application est-elle toujours utilisable? Si vous avez des données obsolètes, est-ce un problème? Peut-être que certaines données critiques doivent être transférées lorsque vous avez GSM/GPRS (ce qui n'est généralement pas gratuit) et que davantage sera fait lorsque vous avez 802.11. Peut-être que vous pouvez courir toute la journée avec des tables de recherche tirées le matin et télécharger uniquement les transactions, avec le dispositif de suivi des changements qu'il est fait.Fondamentalement, cela dépend vraiment de la façon dont il est utilisé, la nature des données, l'importance des transactions de données entre les appareils sur le terrain, l'effet de la latence des données, et probablement d'autres facteurs que je ne peux pas imaginer.
La première étape consiste à déterminer comment l'application doit être utilisée, puis déterminer l'infrastructure et l'architecture pour fournir la connectivité et l'accès aux données requis.
Je n'ai pas utilisé moi-même, mais avez-vous regardé dans le « magasin et en avant » les capacités des FC? Cela peut convenir à vos besoins. Je crois qu'il utilise une boîte aux lettres Exchange en tant que file d'attente de messages pour envoyer des paquets SOAP vers et depuis le périphérique.
La meilleure façon de procéder est de toujours travailler en mode hors connexion, puis utilisez les files d'attente de messages pour gérer l'envoi de modifications et de l'appareil. Lorsque le pilote marque quelque chose comme remis, par exemple, mettez à jour l'élément tel qu'il a été livré dans votre magasin local et placez également un message dans une file d'attente sortante pour indiquer au serveur qu'il a été remis. Une fois la connexion établie, renvoyez tous les éléments mis en file d'attente au serveur et récupérez les messages qui ont été mis en file d'attente depuis le serveur.