Hybride und native Paketierung

Wählen Sie, wie FieldOps die Menschen erreicht, die es verwenden. Disponenten können im Browser arbeiten, während Techniker Zustellungsoptionen benötigen, die an Geräte und unzuverlässige Verbindungen angepasst sind. Die erste Entscheidung betrifft ihre Arbeit, bevor sie sich für ein Paket entscheidet.

Vergleichen Sie vier Clients, die eine Verbindung zum selben Wisej.NET-Server herstellen. Ein Browser oder eine progressive Webanwendung nutzt Webfunktionen. Eine Desktop-Shell WebView2 oder eine Hybrid-Shell Wisej.NET Hybrid fügt einen Host hinzu, der native Gerätefunktionen verfügbar machen kann.

Bewerten Sie gemeinsam Offline-Verhalten, Gerätezugriff, Verteilung, Updates und Kosten. Ein Serverwechsel kann schnell alle erreichen, während eine signierte Shell einen längeren Release-Pfad hat. Dieser Unterschied wirkt sich darauf aus, welche Verantwortlichkeiten auf dem Server verbleiben sollen.

Konzentrieren Sie sich bei jeder Shell darauf, die Browser-Engine zu hosten und Gerätefunktionen verfügbar zu machen. Gemeinsame Bildschirme und Geschäftsverhalten bleiben in einer Serverbereitstellung erhalten. Dünne Shells reduzieren den Umfang der plattformspezifischen Arbeit, die Sie separat verwalten und freigeben müssen.

Fragen Sie den Host, was er unterstützt, bevor Sie eine Geräteaktion anzeigen. Eine alleinige Prüfung auf Android kann einen einfachen Browser nicht von einer fähigen Shell unterscheiden. Eine Fähigkeitsprüfung verknüpft den verfügbaren Befehl mit einer tatsächlichen Implementierung und nicht mit einer Plattformbezeichnung.

Lösen Sie die Funktionen einmal für die Sitzung auf und lassen Sie alle Bildschirme dieses Ergebnis verwenden. Behalten Sie die Statusänderungsregeln in WorkOrderService bei, wobei jeder Client dem gleichen Verhalten folgt. Geräteunterschiede sollten verfügbare Aktionen ändern, ohne dass Geschäftsregeln dupliziert werden.

Die vier Clients zeigen dieselbe Arbeitsauftragsliste von einem Server an. Beachten Sie, dass „Foto aufnehmen“ nur auf dem Telefon mit der angegebenen Funktion angezeigt wird. Der Unterschied ergibt sich aus den Leistungsinformationen der Sitzung, während der freigegebene Bildschirm derselbe bleibt.

Wenn die Konnektivität abbricht, unterscheiden Sie zwischengespeicherte Informationen von der Live-Arbeit. Die Shell und die letzte synchronisierte Zusammenfassung bleiben verfügbar, aber eine unsichtbare Bestellung kann nicht geladen werden. Der Warteschlangenstatus wird explizit identifiziert, sodass der Techniker ihn nicht mit einem abgeschlossenen Server-Update verwechselt.

Erstellen Sie den anfänglichen Listen-, Detail- und Status-Workflow im Browser. Dokumentieren Sie anschließend, welche Lieferziele Sie unterstützen, deren Reihenfolge sowie die Fähigkeitsprüfungen und Akzeptanzkriterien. Die funktionierende Browserversion wird zur gemeinsamen Basis für spätere Shells.

Machen Sie FieldOps installierbar und halten Sie gleichzeitig sein Offline-Versprechen ehrlich. Der Techniker erhält ein Symbol und ein separates Fenster, die Schnittstelle ist jedoch weiterhin auf eine Wisej.NET-Serversitzung angewiesen. Auf der Offline-Seite muss erläutert werden, was verfügbar bleibt, wenn die Verbindung unterbrochen wird.

Folgen Sie dem Techniker von der Depotverbindung in einen Raum ohne Signal. Durch das Zwischenspeichern der Anwendungs-Shell wird das Öffnen erleichtert, eine Live-Wisej.NET-Sitzung bleibt jedoch nicht erhalten. Gestalten Sie das Offline-Erlebnis rund um diese Grenze, anstatt zwischengespeicherte Dateien wie einen laufenden Server zu behandeln.

Verbinden Sie die Installationsteile: eine sichere Verbindung, das von Default.html verknüpfte Manifest, den registrierten Servicemitarbeiter und das erfasste Installationsereignis. Durch die Beibehaltung dieses Ereignisses kann die Seite die Installation später anbieten, wenn der Benutzer sie bewusst auswählt.

Geben Sie Shell-Dateien und Sitzungsverkehr unterschiedliche Routen. Der Worker kann bekannte Shell-Assets aus dem Cache bereitstellen, Sitzungsanfragen müssen jedoch das Netzwerk erreichen. Wenn die Navigation den Server nicht erreichen kann, zeigen Sie die gespeicherte Offline-Seite an, anstatt Sitzungsantworten wiederzugeben.

Passen Sie im Worker eine explizite Shell-Dateiliste an und überspringen Sie Anforderungen, die keine Lesevorgänge sind. Beschränken Sie den Offline-Fallback auf die Navigation. Diese Regeln verhindern, dass zwischengespeicherte Antworten einer abgelaufenen Sitzung so dargestellt werden, als ob die aktuelle Sitzung geantwortet hätte.

Versionieren Sie den Cache, damit das Update ein klares Ziel hat. Der Worker aktiviert und übernimmt die Kontrolle über seine Lebenszyklusmethoden, während der Server die Offline-Zusammenfassung schreibt. Bieten Sie die Installation erst an, nachdem eine erfolgreiche Sitzung gezeigt hat, dass FieldOps funktioniert.

Überprüfen Sie das Manifest, den Worker und neun zwischengespeicherte Shell-Dateien, bevor Sie das Installationsangebot annehmen. Der eigene Klick auf die Seite ruft die gespeicherte Eingabeaufforderung auf. FieldOps wird dann in seinem eigenständigen Fenster geöffnet und zeigt, dass die Installation das Starterlebnis verändert, anstatt den Server auf das Telefon zu verschieben.

Lesen Sie ohne Signal die zwischengespeicherte Zusammenfassung und ihre Synchronisierungszeit. Statusänderungen sind in dieser Version deaktiviert, sodass nichts darauf hindeutet, dass sie in die Warteschlange gestellt wurden. Wenn die Verbindung wiederhergestellt ist, gibt die Neuladeleiste dem Techniker die Kontrolle über die Rückkehr zur Live-Anwendung.

Stellen Sie das Manifest, die Symbole, den versionierten Worker und die Offline-Zusammenfassung als ein einziges Installationserlebnis bereit. Testen Sie das Erstsitzungsangebot und den Update-Pfad. Stellen Sie sicher, dass alte Caches entfernt werden, damit beim nächsten Start nicht weiterhin eine veraltete Shell verwendet wird.

Binden Sie die vorhandene FieldOps-Anwendung in einen Desktop-Host für Techniker ein, die sie während einer Schicht verwenden. Das Fenster, die Tray-Integration und der Installer gehören zur Shell, während die bekannten Bildschirme weiterhin aus der Anwendung Wisej.NET stammen.

Verwenden Sie den WebView2-Host, um die Desktop-Integration bereitzustellen, die diese Bereitstellung benötigt: ein Startsymbol, Taskleistenbenachrichtigungen, eine native Ordnerauswahl und ein installierbares Paket. Diese Ergänzungen umgeben die vorhandene Anwendung, sodass keine Duplizierung der Bildschirme erforderlich ist.

Folgen Sie der Ordneranforderung über die Grenze hinweg. Der Server ruft JavaScript auf, die Seite meldet WebView2 und der Host öffnet den nativen Dialog. Seine strukturierte Antwort kehrt über ein Client-Ereignis an C sharp zurück und vervollständigt eine Anfrage, die beide Prozesse umfasst.

Überprüfen Sie IsDesktopShell, bevor Sie den Host-Befehl senden, und gleichen Sie dann die Antwort-ID mit der Anfrage ab. Die Shell verwaltet die Ordnerauswahl und die Fachbenachrichtigung separat. Durch die Korrelation der Antwort wird sichergestellt, dass eine unabhängige Antwort das Exportziel nicht liefern kann.

Wählen Sie im Rahmen der Bereitstellung den Serverstandort aus. Ein Remote-Server zentralisiert die Anwendung; Ein lokaler Prozess auf dem Laptop dient als Ausweichlösung für die Arbeit ohne Verbindung. Die Startsonde wählt den Pfad aus und macht diese Auswahl für den Techniker sichtbar.

Lesen Sie die Startkonfiguration und prüfen Sie den Serverzustand, bevor Sie mit dem lokalen Fallback beginnen. Stoppen Sie diesen lokalen Prozess, wenn die Shell beendet wird. Sorgen Sie dafür, dass die Aktualisierungsprüfung nicht blockiert, sodass eine fehlgeschlagene Versionssuche den Techniker nicht daran hindert, mit der Arbeit zu beginnen.

Der Export veranschaulicht den kompletten Rundweg: Wählen Sie einen nativen Ordner aus, geben Sie seinen Pfad mit der passenden Kennung zurück und schreiben Sie dann den Bericht. Die Zuweisungsbenachrichtigung übt die umgekehrte Richtung aus und öffnet das Fenster für die entsprechende Bestellung erneut, wenn der Techniker antwortet.

Testen Sie einen neu vorbereiteten Laptop, auf dem die WebView2-Laufzeitumgebung noch nicht vorhanden ist. Das Installationsprogramm liefert es, der Timeout-Probe wählt den lokalen Server aus und der Offline-Streifen erklärt den Modus. Ein verfügbares Update wird angeboten, ohne den aktuellen Job zu unterbrechen.

Stellen Sie die Desktop-Fenster- und Tray-Integration zusammen mit der Ordner- und Benachrichtigungsbrücke bereit. Konfigurieren Sie den Remote-Server und das lokale Fallback und überprüfen Sie dann die Installation und das Update-Angebot zum Startzeitpunkt. Das Ergebnis sollte eine vollständige Desktop-Bereitstellung sein, nicht nur eine gehostete Seite.

Hosten Sie FieldOps in einer kleinen nativen mobilen Shell und behalten Sie dabei die vorhandenen Serverbildschirme bei. Die Projekte Android und iOS fügen Gerätehosting und Lebenszyklusverhalten hinzu. Sie ermöglichen es, dass dieselbe Wisej.NET-Anwendung mobile Benutzer erreicht, ohne dass ihre Formulare für jede Plattform neu erstellt werden müssen.

Der mobile Host muss mehr erledigen als nur die Anzeige einer Seite. Es kann während einer Lektüre angehalten werden, einen Bildschirm mit einer Aussparung belegen oder eine Zurück-Geste empfangen. Planen Sie diese Unterbrechungen und Navigationsverhalten zusammen mit den Installations- und Gerätefunktionen.

Das native Projekt enthält eine Plattform-Webansicht, die sicher mit dem FieldOps-Server verbunden ist. Eine Shell-Änderung folgt dem Veröffentlichungsprozess des Stores; Änderungen an der gehosteten Anwendung bleiben auf dem Server. Wenn Sie diese Grenze freihalten, wird vermieden, dass die Shell für normale Bildschirmänderungen neu erstellt werden muss.

Lesen Sie die Lebenszyklussequenz als Pause-und-Rückkehr-Szenario. Die Anwendung kann während der Abwesenheit des Technikers deaktiviert, gestoppt, fortgesetzt und wieder aktiviert werden. Ob die ursprüngliche Sitzung überlebt, hängt von der verstrichenen Zeit ab. Für die Fortsetzung ist daher eine explizite Entscheidung erforderlich.

Laden Sie die Adresse nicht automatisch bei jedem Lebenslauf neu. Speichern Sie den relevanten Status, wenn der Host stoppt, und entscheiden Sie dann, ob Sie die Verbindung zur Sitzung wiederherstellen oder den gespeicherten Arbeitsauftrag neu laden und erneut öffnen möchten. Dadurch wird die Kontinuität gewahrt, ohne dass davon ausgegangen wird, dass noch eine abgelaufene Sitzung besteht.

Leiten Sie die Zurück-Geste an FieldOps weiter und melden Sie, dass der Host sie verarbeitet hat. Bringen Sie eine Sicherheitsbereichspolsterung an den tatsächlichen Einsätzen der Plattform an. Diese Verantwortlichkeiten liegen beim Host, sodass für einzelne Serverbildschirme keine gerätespezifischen Pixelversätze erforderlich sind.

Führen Sie den Android-Build in seinem Emulator und den iOS-Build über den Mac-Simulatorpfad aus. Beide laden denselben FieldOps-Server. Vergleichen Sie ihre Arbeitsauftragsbildschirme, um sicherzustellen, dass die nativen Ziele die Anwendung gemeinsam nutzen, anstatt separate Bildschirmimplementierungen zu verwenden.

Der eingehende Anruf unterbricht eine Lesung, sodass der Stop-Handler den Entwurf und Zeit spart. Bei der Rückkehr liegen einhundertvierundsiebzig Sekunden immer noch innerhalb der sechshundertsekündigen Auszeit. Durch erneutes Anschließen wird die gleiche Reihenfolge wiederhergestellt, ohne dass der Techniker den Messwert erneut eingeben muss.

Erstellen Sie beide mobilen Ziele und testen Sie den Hintergrund so sorgfältig wie beim ersten Start. Beinhaltet Sitzungswiederherstellung, Rücknavigation und Handhabung sicherer Bereiche. Erfassen Sie die Arbeitsauftragsliste in beiden Emulatoren, damit die Abgabe die gemeinsame Erfahrung auf jeder Plattform demonstriert.

Verbinden Sie FieldOps-Aktionen über die Shell-Bridge mit nativen Gerätefunktionen. Der Techniker kann Geräte fotografieren oder eine Unterschrift erfassen, während die Wisej.NET-Steuerungen auf dem Server verbleiben. Die Bridge überträgt die Anfrage und gibt das endgültige Ergebnis des Geräts zurück.

Verfolgen Sie die Kameraanforderung vom Server über die Seite bis zum Hostobjekt. Das Ergebnis kommt später als Ereignis an, nachdem der ursprüngliche Befehl zurückgegeben wurde. Übertragen Sie die resultierende Schnittstellenänderung mit Application.Update, damit der Techniker die abgeschlossene Aktion sieht.

Verwenden Sie den beim Sitzungsstart gemeldeten Fähigkeitsdeskriptor, um die verfügbaren Aktionen auszuwählen. Der Plattformname eines Browsers beweist nicht, dass die native Bridge existiert. Wenn diese Anbindung nicht verfügbar ist, stellt Upload weiterhin den browserbasierten Pfad zum Auswählen oder Erfassen eines Bildes bereit.

Erklären Sie, warum Zugriff erforderlich ist, wenn der Benutzer die Aktion auswählt, und fordern Sie dann die Erlaubnis an. Gewährte Behandlung, vorübergehende Verweigerung und dauerhafte Verweigerung sind unterschiedliche Ergebnisse. Das wiederholte Öffnen derselben Eingabeaufforderung kann eine dauerhafte Ablehnung nicht lösen und blockiert lediglich den Arbeitsablauf.

Der Click-Handler prüft die Unterstützung, erstellt ein Anforderungstoken und kehrt umgehend zurück. OnShellResult überprüft später, ob die Antwort noch relevant ist, kümmert sich um den Abbruch und speichert erfolgreiche Bilddaten. Der Abgleich des Tokens verhindert, dass eine alte Antwort den falschen Status aktualisiert.

Ändern Sie für den Browserpfad die Größe des hochgeladenen Bildes, bevor Sie es außerhalb öffentlich zugänglicher Speicherorte speichern. Die Navigation erklärt ihre Standortanfrage separat. Wenn die Erlaubnis verweigert wird, akzeptieren Sie eine eingegebene Adresse, damit das Vervollständigen der Route nicht von der Gewährung des Standortzugriffs abhängt.

Sehen Sie, wie die Android-Hülle zwei Fotos und eine Signatur vervollständigt. Jeder Vorgang erscheint als separater Bridge-Aufruf im Protokoll. Der ursprüngliche Klick wurde bereits zurückgegeben, bevor die Daten eintrafen, was bestätigt, dass Gerätevorgänge über ihre Ergebnisereignisse asynchron abgeschlossen werden.

Öffnen Sie denselben Bildschirm in einem einfachen Browser und vergleichen Sie die verfügbaren Aktionen. „Upload“ ersetzt den nicht unterstützten nativen Kamerabefehl. Geben Sie den Standort ab, geben Sie eine Adresse ein und fahren Sie mit der Route fort. Der Fallback behält die Aufgabe auch dann bei, wenn der Gerätezugriff nicht verfügbar ist.

Implementieren Sie die Aktionen „Foto“, „Signatur“, „Navigation“ und „Aufgabenbenachrichtigung“ mit ihren Funktionsregeln. Fügen Sie den Browser-Upload-Fallback und die Pfade für verweigerte Berechtigungen hinzu. Die Fähigkeitsmatrix sollte erklären, warum jeder Client seine besonderen Aktionen anbietet und wie der Benutzer fortfährt, wenn der Zugriff fehlschlägt.

Bereiten Sie FieldOps für die Lieferung über die Entwicklungsmaschinen hinaus vor. Ein Server unterstützt vier Client-Formulare, aber die drei nativen Pakete benötigen jeweils eine akzeptierte Signaturidentität. Zur Release-Bereitschaft gehören daher die Verteilung und Kompatibilität sowie funktionierende Anwendungsbildschirme.

Eine erfolgreiche Serverbereitstellung ist keine Garantie für eine erfolgreiche Veröffentlichung. Ein unbekannter Desktop-Publisher, ein abgelaufenes mobiles Profil oder eine alte Shell, die eine entfernte Methode aufruft, können Techniker weiterhin blockieren. Überprüfen Sie diese unabhängigen Fehlerpunkte, bevor Sie den Rollout als abgeschlossen bezeichnen.

Behandeln Sie die Signaturidentität jeder Plattform als Herkunftsnachweis. Windows verwendet sein Zertifikat und seinen Zeitstempel, Android seinen Upload-Schlüssel und seinen Signaturdienst und Apple sein Verteilungszertifikat und Profil. Durch die Signatur wird der Herausgeber identifiziert; Es ersetzt nicht die Kompatibilitätsprüfung.

Wählen Sie den Vertriebskanal für jede native Plattform separat aus: verwaltete Stores, Geräteverwaltung oder signierter Download. Stattdessen folgt die Bereitstellung von Browsern und progressiven Webanwendungen dem Webbereitstellungspfad. Der Kanal bestimmt, wie Techniker das Paket tatsächlich empfangen und aktualisieren.

Erzwingen Sie die Shell-Version beim Start der Sitzung, anstatt sie nur anzuzeigen. AdmitShell vergleicht die gemeldete Version mit dem Minimum der Plattform und zeichnet das Ergebnis im Sitzungsstatus auf. Der Server kann dann ein Update zulassen, warnen oder gezielt anfordern.

Sammeln Sie Beweise von beiden Seiten der Grenze. Eine Absturzberichtsbibliothek in der Shell erkennt Fehler, die der Server nicht sehen kann. Gerätefunktionsereignisse fügen Ergebnis, Plattform und Shell-Version hinzu und helfen so, ein Geräteintegrationsproblem von einem serverseitigen Problem zu unterscheiden.

Vergleichen Sie die drei Clients, die den aktualisierten Server erreichen. Der Desktop wird fortgesetzt, iOS erhält eine Abweisungsbenachrichtigung und die alte Android-Shell bleibt beim Aktualisierungsbildschirm stehen. Die Prüfung erfolgt vor dem Laden von Bestellungen, sodass ein inkompatibler Client den Workflow nicht starten kann.

Verwenden Sie eine Release-Checklistenzeile pro Bereitstellungspfad, damit sich kein Paket hinter der erfolgreichen Bereitstellung des Servers verbirgt. Überprüfen Sie die Standortverweigerungsereignisse als Workflow-Beweis: Eine zu früh gestellte Berechtigungsanfrage erfordert eine Änderung des Timings, anstatt davon auszugehen, dass die Standortfunktion fehlerhaft ist.

Vervollständigen Sie das Abschlussprojekt mit unterzeichneten Paketen, ausgewählten Unternehmenskanälen und einem Listenentwurf. Fügen Sie Startkompatibilitätsprüfungen sowie Absturz- und Nutzungsberichte hinzu. Übergeben Sie die Release-Checkliste, damit eine andere Person die Bereitstellungs-, Update- und Wiederherstellungspfade für jeden Client überprüfen kann.