Packaging hybride et natif

Choisissez comment FieldOps atteint les personnes qui l'utilisent. Les répartiteurs peuvent travailler dans un navigateur, tandis que les techniciens ont besoin d'options de livraison adaptées aux appareils et aux connexions peu fiables. La première décision concerne leur travail, avant de choisir un forfait.

Comparez quatre clients qui se connectent au même serveur Wisej.NET. Un navigateur ou une application Web progressive utilise les fonctionnalités Web ; un shell WebView2 de bureau ou un shell mobile hybride Wisej.NET ajoute un hôte qui peut exposer les fonctionnalités natives du périphérique.

Évaluez ensemble le comportement hors ligne, l’accès aux appareils, la distribution, les mises à jour et les coûts. Un changement de serveur peut atteindre tout le monde rapidement, tandis qu'un shell signé a un chemin de publication plus long. Cette différence affecte les responsabilités qui doivent rester sur le serveur.

Gardez chaque shell concentré sur l’hébergement du moteur du navigateur et l’exposition des fonctionnalités de l’appareil. Les écrans partagés et le comportement professionnel restent dans un seul déploiement de serveur. Les coques fines réduisent la quantité de travail spécifique à la plate-forme que vous devez maintenir et publier séparément.

Demandez à l'hôte ce qu'il prend en charge avant d'afficher une action de l'appareil. La vérification uniquement de Android ne permet pas de distinguer un navigateur simple d'un shell capable. Une vérification de capacité lie la commande disponible à une implémentation réelle au lieu d'une étiquette de plate-forme.

Résolvez les capacités une fois pour la session et laissez tous les écrans utiliser ce résultat. Conservez les règles de changement de statut dans WorkOrderService, où chaque client suit le même comportement. Les différences entre les appareils doivent modifier les actions disponibles sans dupliquer les règles métier.

Les quatre clients affichent la même liste de bons de travail à partir d'un serveur. Notez que Prendre une photo apparaît uniquement sur le téléphone doté de la fonctionnalité signalée. La différence vient des informations de capacité de la session, tandis que l’écran partagé reste le même.

Lorsque la connectivité tombe, distinguez les informations mises en cache du travail en direct. Le shell et le dernier résumé synchronisé restent disponibles, mais une commande invisible ne peut pas se charger. L'état de la file d'attente est explicitement identifié afin que le technicien ne le confonde pas avec une mise à jour du serveur terminée.

Créez la liste initiale, les détails et le flux de travail de statut dans le navigateur. Documentez ensuite les objectifs de livraison que vous prendrez en charge, leur commande, ainsi que les contrôles de capacité et les critères d'acceptation. La version de travail du navigateur devient la référence partagée pour les shells ultérieurs.

Rendre FieldOps installable tout en gardant sa promesse hors ligne honnête. Le technicien obtient une icône et une fenêtre séparée, mais l'interface dépend toujours d'une session serveur Wisej.NET. La page hors ligne doit expliquer ce qui reste disponible lorsque cette connexion disparaît.

Suivez le technicien depuis la connectivité du dépôt dans une pièce sans signal. La mise en cache du shell de l'application facilite son ouverture, mais ne préserve pas une session Wisej.NET en direct. Concevez l'expérience hors ligne autour de cette limite au lieu de traiter les fichiers mis en cache comme un serveur en cours d'exécution.

Connectez les éléments d'installation : une connexion sécurisée, le manifeste lié à partir de Default.html, le technicien de service enregistré et l'événement d'installation capturé. Conserver cet événement permet à la page de proposer une installation ultérieure, lorsque l'utilisateur le choisit délibérément.

Donnez des itinéraires différents aux fichiers shell et au trafic de session. Le travailleur peut servir les actifs shell connus à partir du cache, mais les demandes de session doivent atteindre le réseau. Si la navigation ne parvient pas à atteindre le serveur, affichez la page hors ligne enregistrée au lieu de relire les réponses de la session.

Dans le travailleur, faites correspondre une liste de fichiers shell explicite et ignorez les requêtes qui ne sont pas des lectures. Restreindre le repli hors ligne à la navigation. Ces règles empêchent que les réponses mises en cache d'une session expirée soient présentées comme si la session en cours avait répondu.

Versionnez le cache pour que la mise à jour ait une destination claire. Le travailleur active et prend le contrôle via ses méthodes de cycle de vie, tandis que le serveur rédige le résumé hors ligne. Proposez l'installation uniquement après qu'une session réussie ait démontré que FieldOps fonctionne.

Vérifiez le manifeste, le travailleur et les neuf fichiers shell mis en cache avant d'accepter l'offre d'installation. Le propre clic de la page appelle l’invite stockée. FieldOps s'ouvre alors dans sa fenêtre autonome, montrant que l'installation modifie l'expérience de lancement plutôt que de déplacer le serveur sur le téléphone.

Sans signal, lisez le résumé mis en cache et son heure de synchronisation. Les changements de statut sont désactivés dans cette version, donc rien ne suggère qu'ils ont été mis en file d'attente. Lorsque la connectivité revient, la barre de rechargement donne au technicien le contrôle du retour à l'application en direct.

Fournissez le manifeste, les icônes, le travailleur versionné et le résumé hors ligne en une seule expérience d'installation. Testez l'offre de première session et le chemin de mise à jour. Confirmez que les anciens caches sont supprimés afin que le prochain lancement ne continue pas à utiliser un shell obsolète.

Enveloppez l'application FieldOps existante dans un hôte de bureau pour les techniciens qui l'utilisent tout au long d'un quart de travail. La fenêtre, l'intégration de la barre d'état et le programme d'installation appartiennent au shell, tandis que les écrans familiers continuent de provenir de l'application Wisej.NET.

Utilisez l'hôte WebView2 pour fournir l'intégration de bureau dont cette livraison a besoin : une icône de lancement, des notifications dans la barre d'état système, un sélecteur de dossiers natif et un package installable. Ces ajouts entourent l’application existante, ils ne nécessitent donc pas de dupliquer ses écrans.

Suivez la demande de dossier au-delà des limites. Le serveur appelle JavaScript, la page envoie des messages WebView2 et l'hôte ouvre la boîte de dialogue native. Sa réponse structurée est renvoyée via un événement client à C sharp, complétant une requête qui couvre les deux processus.

Vérifiez IsDesktopShell avant d'envoyer la commande hôte, puis faites correspondre l'identifiant de la réponse à la demande. Le shell gère séparément la sélection des dossiers et la notification dans la barre d'état. La corrélation des réponses garantit qu'une réponse sans rapport ne peut pas fournir la destination de l'exportation.

Choisissez l'emplacement du serveur dans le cadre du déploiement. Un serveur distant centralise l'application ; un processus local sur l'ordinateur portable fournit une solution de repli pour le travail déconnecté. La sonde de lancement sélectionne le chemin et rend ce choix visible au technicien.

Lisez la configuration de lancement et sondez l’état du serveur avant de démarrer la solution de secours locale. Arrêtez ce processus local lorsque le shell se termine. Gardez la vérification des mises à jour non bloquante, de sorte qu'un échec de recherche de version n'empêche pas le technicien de commencer son travail.

L'export démontre l'aller-retour complet : choisissez un dossier natif, renvoyez son chemin avec l'identifiant correspondant, puis rédigez le rapport. La notification d'affectation exerce l'autre sens, en rouvrant la fenêtre sur l'ordre concerné lorsque le technicien répond.

Testez un ordinateur portable nouvellement préparé sur lequel le runtime WebView2 n'est pas encore présent. Le programme d'installation le fournit, la sonde d'expiration du délai sélectionne le serveur local et la bande hors ligne explique le mode. Une mise à jour disponible est proposée sans interrompre le travail en cours.

Fournissez l'intégration de la fenêtre du bureau et de la barre d'état avec le dossier et le pont de notification. Configurez le serveur distant et la solution de secours locale, puis vérifiez l'installation et l'offre de mise à jour au lancement. Le résultat devrait être une livraison de bureau complète, pas seulement une page hébergée.

Hébergez FieldOps dans un petit shell mobile natif tout en conservant ses écrans de serveur existants. Les projets Android et iOS ajoutent l'hébergement des appareils et le comportement du cycle de vie. Ils permettent à la même application Wisej.NET d'atteindre les utilisateurs mobiles sans recréer ses formulaires pour chaque plateforme.

L’hébergeur mobile doit gérer bien plus que l’affichage d’une page. Il peut être suspendu lors d'une lecture, occuper un écran doté d'une encoche, ou recevoir un geste de retour. Planifiez ces interruptions et ces comportements de navigation en fonction des fonctionnalités d'installation et de l'appareil.

Le projet natif contient une vue Web de plateforme connectée de manière sécurisée au serveur FieldOps. Un changement de shell suit le processus de publication du magasin ; les modifications apportées à l'application hébergée restent sur le serveur. Garder cette limite claire évite de reconstruire le shell pour les changements d'écran ordinaires.

Lisez la séquence du cycle de vie comme un scénario de pause et de retour. L'application peut se désactiver, s'arrêter, reprendre et se réactiver pendant l'absence du technicien. La survie de la session d'origine dépend du temps écoulé, la reprise nécessite donc une décision explicite.

Ne rechargez pas l’adresse automatiquement sur chaque CV. Enregistrez l'état concerné lorsque l'hôte s'arrête, puis décidez de vous reconnecter à la session ou de recharger et de rouvrir l'ordre de travail enregistré. Cela préserve la continuité sans supposer qu’une session expirée existe toujours.

Acheminez le geste de retour vers FieldOps et signalez que l'hôte l'a traité. Appliquez un rembourrage de zone de sécurité à partir des encarts réels de la plate-forme. Ces responsabilités appartiennent à l'hôte, de sorte que les écrans de serveurs individuels n'ont pas besoin de décalages de pixels spécifiques à l'appareil.

Exécutez la build Android dans son émulateur et la build iOS via le chemin du simulateur Mac. Les deux chargent le même serveur FieldOps. Comparez leurs écrans de bons de travail pour confirmer que les cibles natives partagent l'application au lieu d'effectuer des implémentations d'écran distinctes.

L'appel entrant interrompt une lecture, de sorte que le gestionnaire d'arrêt enregistre le brouillon et l'heure. Au retour, cent soixante-quatorze secondes se situent toujours dans le délai d'attente de six cent secondes. La reconnexion rétablit le même ordre sans demander au technicien de retaper la lecture.

Créez à la fois des cibles mobiles et testez l’arrière-plan aussi soigneusement que le premier lancement. Incluez la récupération de session, la navigation arrière et la gestion des zones de sécurité. Capturez la liste des bons de travail dans les deux émulateurs afin que la remise démontre l'expérience partagée sur chaque plate-forme.

Connectez les actions FieldOps aux fonctionnalités natives de l'appareil via le pont shell. Le technicien peut photographier l'équipement ou capturer une signature, tandis que les commandes Wisej.NET restent sur le serveur. Le pont transporte la demande et renvoie le résultat final de l'appareil.

Suivez la demande de caméra depuis le serveur, via la page, jusqu'à l'objet hôte. Le résultat arrive plus tard sous forme d'événement, après le retour de la commande d'origine. Poussez le changement d'interface résultant avec Application.Update afin que le technicien voie l'action terminée.

Utilisez le descripteur de capacité signalé au début de la session pour choisir les actions disponibles. Le nom de la plateforme d’un navigateur ne prouve pas que le pont natif existe. Lorsque ce pont n'est pas disponible, Upload fournit toujours le chemin basé sur le navigateur pour sélectionner ou capturer une image.

Expliquez pourquoi l'accès est nécessaire lorsque l'utilisateur choisit l'action, puis demandez l'autorisation. Traitez les résultats accordés, temporairement refusés et définitivement refusés comme des résultats différents. L'ouverture répétée de la même invite ne peut pas résoudre un refus permanent et bloque uniquement le flux de travail.

Le gestionnaire de clics vérifie la prise en charge, crée un jeton de demande et renvoie rapidement. OnShellResult vérifie ultérieurement que la réponse est toujours pertinente, gère l'annulation et stocke les données d'image réussies. Faire correspondre le jeton empêche une ancienne réponse de mettre à jour le mauvais état.

Pour le chemin du navigateur, redimensionnez l'image téléchargée avant de la stocker en dehors d'emplacements adressables publiquement. La navigation explique séparément sa demande de localisation. Si l'autorisation est refusée, acceptez une adresse saisie afin que la réalisation de l'itinéraire ne dépende pas de l'octroi de l'accès à la localisation.

Regardez la coque Android compléter deux photographies et une signature. Chaque opération apparaît comme un appel de pont distinct dans le journal. Le clic d'origine a déjà été renvoyé avant l'arrivée des données, confirmant que les opérations de l'appareil se terminent de manière asynchrone via leurs événements de résultat.

Ouvrez le même écran dans un navigateur simple et comparez ses actions disponibles. Le téléchargement remplace la commande de caméra native non prise en charge. Refuser la localisation, saisir une adresse et continuer l'itinéraire ; la solution de secours préserve la tâche même lorsque l'accès au périphérique n'est pas disponible.

Implémentez les actions de photo, de signature, de navigation et de notification d'affectation avec leurs règles de capacité. Incluez les chemins de secours de téléchargement du navigateur et les chemins d’autorisation refusée. La matrice de capacités doit expliquer pourquoi chaque client propose ses actions particulières et comment l'utilisateur continue lorsque l'accès échoue.

Préparez le FieldOps pour une livraison au-delà des machines de développement. Un serveur prend en charge quatre formulaires client, mais les trois packages natifs nécessitent chacun une identité de signature acceptée. La préparation à la sortie inclut donc la distribution et la compatibilité ainsi que les écrans d'application fonctionnels.

Un déploiement de serveur réussi ne garantit pas une version réussie. Un éditeur de bureau inconnu, un profil mobile expiré ou un ancien shell appelant une méthode supprimée peut toujours bloquer les techniciens. Examinez ces points de défaillance indépendants avant de déclarer le déploiement terminé.

Considérez l’identité de signature de chaque plateforme comme une preuve d’origine. Windows utilise son certificat et son horodatage, Android sa clé de téléchargement et son service de signature, et Apple son certificat et son profil de distribution. La signature identifie l'éditeur ; il ne remplace pas les tests de compatibilité.

Choisissez le canal de distribution séparément pour chaque plateforme native : magasins gérés, gestion des appareils ou téléchargement signé. La livraison par navigateur et application Web progressive suit plutôt le chemin de déploiement Web. Le canal détermine la manière dont les techniciens reçoivent et mettent réellement à jour le package.

Appliquez la version shell au démarrage de la session au lieu de simplement l'afficher. AdmitShell compare la version rapportée avec la version minimale de la plateforme et enregistre le résultat dans l'état de session. Le serveur peut alors admettre, avertir ou exiger délibérément une mise à jour.

Recueillez des preuves des deux côtés de la frontière. Une bibliothèque de rapports de crash à l'intérieur du shell détecte les échecs que le serveur ne peut pas voir. Les événements de fonctionnalité de périphérique ajoutent le résultat, la plate-forme et la version du shell, permettant ainsi de distinguer un problème d'intégration de périphérique d'un problème côté serveur.

Comparez les trois clients atteignant le serveur mis à jour. Le bureau continue, iOS reçoit un avis de rejet et l'ancien shell Android s'arrête à l'écran de mise à jour. La vérification a lieu avant le chargement des commandes, donc un client incompatible ne peut pas démarrer le workflow.

Utilisez une ligne de liste de contrôle de version par chemin de livraison afin qu'aucun package ne se cache derrière le déploiement réussi du serveur. Examinez les événements de refus de localisation comme preuve du flux de travail : une demande d'autorisation effectuée trop tôt nécessite un changement de timing plutôt que de supposer que la fonctionnalité de localisation est interrompue.

Complétez la synthèse avec des packages signés, des canaux d'entreprise choisis et un brouillon de liste. Ajoutez des contrôles de compatibilité au démarrage et des rapports de plantage et d'utilisation. Remettez la liste de contrôle de publication afin qu'une autre personne puisse vérifier les chemins de livraison, de mise à jour et de récupération pour chaque client.