Pacchetti ibridi e nativi

Scegli come FieldOps raggiunge le persone che lo utilizzano. Gli spedizionieri possono lavorare in un browser, mentre i tecnici necessitano di opzioni di consegna adatte a dispositivi e connessioni inaffidabili. La prima decisione riguarda il proprio lavoro, prima di scegliere un pacchetto.

Confronta quattro client che si connettono allo stesso server Wisej.NET. Un browser o un'applicazione web progressiva utilizza funzionalità web; una shell desktop WebView2 o una shell mobile ibrida Wisej.NET aggiunge un host in grado di esporre le funzionalità native del dispositivo.

Valuta insieme il comportamento offline, l'accesso ai dispositivi, la distribuzione, gli aggiornamenti e i costi. Un cambio di server può raggiungere rapidamente tutti, mentre una shell firmata ha un percorso di rilascio più lungo. Questa differenza influisce sulle responsabilità che devono rimanere sul server.

Mantieni ogni shell focalizzata sull'hosting del motore del browser e sull'esposizione delle funzionalità del dispositivo. Gli schermi condivisi e il comportamento aziendale rimangono nella distribuzione di un unico server. Le shell sottili riducono la quantità di lavoro specifico della piattaforma che devi mantenere e rilasciare separatamente.

Chiedi all'host cosa supporta prima di mostrare un'azione del dispositivo. Controllando solo Android non è possibile distinguere un browser semplice da una shell capace. Un controllo di capacità lega il comando disponibile a un'implementazione effettiva invece che a un'etichetta di piattaforma.

Risolvere le funzionalità una volta per la sessione e consentire a tutti gli schermi di utilizzare quel risultato. Mantieni le regole di modifica dello stato in WorkOrderService, dove ogni client segue lo stesso comportamento. Le differenze tra i dispositivi dovrebbero modificare le azioni disponibili senza duplicare le regole aziendali.

I quattro client visualizzano lo stesso elenco di ordini di lavoro da un server. Tieni presente che Scatta foto viene visualizzato solo sul telefono con la funzionalità segnalata. La differenza deriva dalle informazioni sulla capacità della sessione, mentre lo schermo condiviso rimane lo stesso.

Quando la connettività diminuisce, distingui le informazioni memorizzate nella cache dal lavoro dal vivo. La shell e l'ultimo riepilogo sincronizzato rimangono disponibili, ma non è possibile caricare un ordine invisibile. Lo stato in coda viene identificato esplicitamente in modo che il tecnico non lo confonda con un aggiornamento del server completato.

Crea l'elenco iniziale, i dettagli e il flusso di lavoro dello stato nel browser. Quindi documenta quali obiettivi di consegna supporterai, il loro ordine, i controlli di capacità e i criteri di accettazione. La versione del browser funzionante diventa la base condivisa per le shell successive.

Rendi FieldOps installabile mantenendo onesta la sua promessa offline. Il tecnico ottiene un'icona e una finestra separata, ma l'interfaccia dipende ancora da una sessione del server Wisej.NET. La pagina offline deve spiegare cosa rimane disponibile quando tale connessione scompare.

Segui il tecnico dalla connettività del deposito in una stanza senza segnale. La memorizzazione nella cache della shell dell'applicazione ne facilita l'apertura, ma non preserva una sessione Wisej.NET live. Progetta l'esperienza offline attorno a quel limite invece di trattare i file memorizzati nella cache come un server in esecuzione.

Connetti i componenti dell'installazione: una connessione sicura, il manifest collegato da Default.html, l'addetto ai servizi registrato e l'evento di installazione acquisito. Il mantenimento di tale evento consente alla pagina di offrire l'installazione in un secondo momento, quando l'utente lo sceglie deliberatamente.

Assegna ai file della shell e al traffico della sessione percorsi diversi. Il lavoratore può servire le risorse della shell conosciute dalla cache, ma le richieste di sessione devono raggiungere la rete. Se la navigazione non riesce a raggiungere il server, mostra la pagina offline salvata invece di riprodurre le risposte della sessione.

Nel lavoratore, abbina un elenco esplicito di file di shell e salta le richieste che non sono letture. Limita il fallback offline alla navigazione. Queste regole impediscono che le risposte memorizzate nella cache di una sessione scaduta vengano presentate come se la sessione corrente avesse risposto.

Versione della cache in modo che l'aggiornamento abbia una destinazione chiara. Il lavoratore si attiva e prende il controllo attraverso i metodi del suo ciclo di vita, mentre il server scrive il riepilogo offline. Offri l'installazione solo dopo che una sessione riuscita ha dimostrato che FieldOps funziona.

Controlla il manifest, il lavoratore e i nove file della shell memorizzati nella cache prima di accettare l'offerta di installazione. Il clic della pagina richiama il prompt memorizzato. FieldOps si apre quindi nella sua finestra autonoma, mostrando che l'installazione modifica l'esperienza di avvio anziché spostare il server sul telefono.

Senza segnale, leggi il riepilogo memorizzato nella cache e l'ora di sincronizzazione. I cambiamenti di stato sono disabilitati in questa versione, quindi nulla suggerisce che siano stati messi in coda. Quando la connettività ritorna, la barra Ricarica dà al tecnico il controllo sul ritorno all'applicazione live.

Fornisci manifest, icone, lavoratore con versione e riepilogo offline come un'unica esperienza di installazione. Testare l'offerta della prima sessione e il percorso di aggiornamento. Confermare che le vecchie cache siano state rimosse in modo che al prossimo avvio non continui a utilizzare una shell obsoleta.

Integra l'applicazione FieldOps esistente in un host desktop per i tecnici che la utilizzano durante un turno. La finestra, l'integrazione del vassoio e il programma di installazione appartengono alla shell, mentre le schermate familiari continuano a provenire dall'applicazione Wisej.NET.

Utilizza l'host WebView2 per fornire l'integrazione desktop necessaria per questa consegna: un'icona di avvio, notifiche sulla barra delle applicazioni, un selettore di cartelle nativo e un pacchetto installabile. Queste aggiunte circondano l'applicazione esistente, quindi non richiedono la duplicazione delle sue schermate.

Segui la richiesta della cartella oltre il confine. Il server richiama JavaScript, la pagina invia i messaggi WebView2 e l'host apre la finestra di dialogo nativa. La sua risposta strutturata ritorna tramite un evento client a C sharp, completando una richiesta che abbraccia entrambi i processi.

Controlla IsDesktopShell prima di inviare il comando host, quindi abbina l'identificatore della risposta alla richiesta. La shell gestisce separatamente la selezione delle cartelle e la notifica del vassoio. La correlazione della risposta garantisce che una risposta non correlata non possa fornire la destinazione dell'esportazione.

Scegli la posizione del server come parte della distribuzione. Un server remoto centralizza l'applicazione; un processo locale sul laptop fornisce il fallback per il lavoro disconnesso. La sonda di lancio seleziona il percorso e rende visibile la scelta al tecnico.

Leggere la configurazione di avvio e verificare l'integrità del server prima di avviare il fallback locale. Arresta il processo locale quando la shell esce. Mantieni il controllo degli aggiornamenti non bloccante, in modo che una ricerca della versione non riuscita non impedisca al tecnico di iniziare il lavoro.

L'esportazione dimostra il viaggio di andata e ritorno completo: scegli una cartella nativa, restituisci il suo percorso con l'identificatore corrispondente, quindi scrivi il report. La notifica di assegnazione esercita la direzione opposta, riaprendo la finestra sull'ordine interessato quando il tecnico risponde.

Testare un laptop appena preparato in cui il runtime WebView2 non è ancora presente. L'installatore lo fornisce, la sonda scaduta seleziona il server locale e la striscia offline spiega la modalità. Viene offerto un aggiornamento disponibile senza interrompere il lavoro corrente.

Fornisci l'integrazione della finestra del desktop e della barra delle applicazioni insieme alla cartella e al bridge di notifica. Configura il server remoto e il fallback locale, quindi verifica l'installazione e l'offerta di aggiornamento al momento del lancio. Il risultato dovrebbe essere una distribuzione desktop completa, non solo una pagina ospitata.

Ospita FieldOps in una piccola shell mobile nativa mantenendo le schermate del server esistente. I progetti Android e iOS aggiungono hosting dei dispositivi e comportamento del ciclo di vita. Consentono alla stessa applicazione Wisej.NET di raggiungere gli utenti mobili senza ricrearne i moduli per ciascuna piattaforma.

L'host mobile deve gestire più della semplice visualizzazione di una pagina. Può essere sospeso durante la lettura, occupare uno schermo dotato di notch o ricevere un gesto indietro. Pianifica queste interruzioni e comportamenti di navigazione insieme all'installazione e alle funzionalità del dispositivo.

Il progetto nativo contiene una visualizzazione Web della piattaforma connessa in modo sicuro al server FieldOps. Una modifica alla shell segue il processo di rilascio del negozio; le modifiche all'applicazione ospitata rimangono sul server. Mantenere questo confine chiaro evita di ricostruire la shell per le normali modifiche dello schermo.

Leggi la sequenza del ciclo di vita come uno scenario di pausa e ritorno. L'applicazione può disattivarsi, arrestarsi, riprendere e attivarsi nuovamente mentre il tecnico è assente. La sopravvivenza della sessione originale dipende dal tempo trascorso, quindi per riprenderla è necessaria una decisione esplicita.

Non ricaricare l'indirizzo automaticamente ad ogni curriculum. Salva lo stato rilevante quando l'host si ferma, quindi decidi se riconnetterti alla sessione o ricaricare e riaprire l'ordine di lavoro salvato. Ciò preserva la continuità senza presupporre che esista ancora una sessione scaduta.

Indirizza il gesto Indietro in FieldOps e segnala che l'host lo ha gestito. Applicare l'imbottitura dell'area sicura dagli inserti effettivi della piattaforma. Queste responsabilità appartengono all'host, quindi gli schermi dei singoli server non necessitano di offset pixel specifici del dispositivo.

Esegui la build Android nel suo emulatore e la build iOS attraverso il percorso del simulatore Mac. Entrambi caricano lo stesso server FieldOps. Confronta le schermate dell'ordine di lavoro per confermare che i target nativi condividono l'applicazione invece di portare implementazioni di schermate separate.

La chiamata in arrivo interrompe una lettura, quindi il gestore dell'interruzione salva la bozza e l'ora. Al ritorno, centosettantaquattro secondi sono ancora entro il timeout di seicento secondi. La riconnessione ripristina lo stesso ordine senza chiedere al tecnico di digitare nuovamente la lettura.

Costruisci entrambi i target mobili e testa il background con la stessa attenzione del primo lancio. Include il recupero della sessione, la navigazione all'indietro e la gestione dell'area sicura. Cattura l'elenco degli ordini di lavoro in entrambi gli emulatori in modo che la consegna dimostri l'esperienza condivisa su ciascuna piattaforma.

Connetti le azioni FieldOps alle funzionalità native del dispositivo tramite lo shell bridge. Il tecnico può fotografare l'apparecchiatura o acquisire una firma, mentre i controlli Wisej.NET rimangono sul server. Il bridge trasporta la richiesta e restituisce il risultato finale del dispositivo.

Traccia la richiesta della telecamera dal server, attraverso la pagina, all'oggetto host. Il risultato arriva più tardi come evento, dopo la restituzione del comando originale. Invia la modifica dell'interfaccia risultante con Application.Update in modo che il tecnico possa vedere l'azione completata.

Utilizza il descrittore di capacità riportato all'inizio della sessione per scegliere le azioni disponibili. Il nome della piattaforma di un browser non dimostra che esista il bridge nativo. Laddove il bridge non è disponibile, Carica fornisce comunque il percorso basato sul browser per selezionare o acquisire un'immagine.

Spiega perché è necessario l'accesso quando l'utente sceglie l'azione, quindi richiedi l'autorizzazione. Trattare concesso, temporaneamente negato e permanentemente negato come risultati diversi. L'apertura ripetuta dello stesso prompt non può risolvere un rifiuto permanente e blocca solo il flusso di lavoro.

Il gestore dei clic controlla il supporto, crea un token di richiesta e restituisce tempestivamente. OnShellResult verifica successivamente che la risposta sia ancora pertinente, gestisce l'annullamento e memorizza i dati dell'immagine corretti. La corrispondenza del token impedisce a una vecchia risposta di aggiornare lo stato sbagliato.

Per il percorso del browser, ridimensiona l'immagine caricata prima di archiviarla al di fuori di posizioni indirizzabili pubblicamente. La navigazione spiega separatamente la sua richiesta di posizione. Se l'autorizzazione viene rifiutata, accetta un indirizzo digitato in modo che il completamento del percorso non dipenda dalla concessione dell'accesso alla posizione.

Osserva la shell Android mentre completa due fotografie e una firma. Ogni operazione compare nel registro come una chiamata distinta al bridge. Il gestore del clic iniziale è già terminato quando arrivano i dati: questo conferma che le operazioni del dispositivo si completano in modo asincrono tramite gli eventi che ne riportano il risultato.

Apri la stessa schermata in un semplice browser e confronta le azioni disponibili. Il caricamento sostituisce il comando nativo della fotocamera non supportato. Rifiuta la posizione, inserisci un indirizzo e prosegui con il percorso; il fallback preserva l'attività anche quando l'accesso al dispositivo non è disponibile.

Implementa le azioni relative a foto, firma, navigazione e notifica di assegnazione con le relative regole di capacità. Includere il fallback di caricamento del browser e i percorsi di autorizzazione negata. La matrice delle capacità dovrebbe spiegare perché ogni client offre le sue azioni particolari e come l'utente continua quando l'accesso fallisce.

Preparare FieldOps per la consegna oltre le macchine di sviluppo. Un server supporta quattro moduli client, ma i tre pacchetti nativi necessitano ciascuno di un'identità di firma accettata. La disponibilità del rilascio include quindi la distribuzione e la compatibilità, nonché le schermate delle applicazioni funzionanti.

Una distribuzione server riuscita non garantisce un rilascio riuscito. Un editore desktop sconosciuto, un profilo mobile scaduto o una vecchia shell che richiama un metodo rimosso possono comunque bloccare i tecnici. Esaminare questi punti di errore indipendenti prima di definire completata l'implementazione.

Tratta l'identità della firma di ciascuna piattaforma come prova di origine. Windows utilizza il suo certificato e il timestamp, Android la sua chiave di caricamento e il servizio di firma e Apple il suo certificato di distribuzione e il suo profilo. La firma identifica l'editore; non sostituisce il test di compatibilità.

Scegli il canale di distribuzione separatamente per ciascuna piattaforma nativa: negozi gestiti, gestione dei dispositivi o download firmato. La distribuzione progressiva del browser e delle applicazioni Web segue invece il percorso di distribuzione Web. Il canale determina il modo in cui i tecnici ricevono e aggiornano effettivamente il pacchetto.

Applica la versione della shell all'avvio della sessione invece di limitarsi a visualizzarla. AdmitShell confronta la versione riportata con quella minima della piattaforma e registra il risultato nello stato della sessione. Il server può quindi ammettere, avvisare o richiedere deliberatamente un aggiornamento.

Raccogli prove da entrambi i lati del confine. Una libreria di segnalazione degli arresti anomali all'interno della shell rileva gli errori che il server non può vedere. Gli eventi delle funzionalità del dispositivo aggiungono risultato, piattaforma e versione della shell, aiutando a distinguere un problema di integrazione del dispositivo da un problema lato server.

Confronta i tre client che raggiungono il server aggiornato. Il desktop procede, iOS riceve un avviso ignorabile e la vecchia shell Android si ferma alla schermata di aggiornamento. Il controllo avviene prima del caricamento degli ordini, quindi un cliente incompatibile non può iniziare il flusso di lavoro.

Utilizza una riga dell'elenco di controllo del rilascio per percorso di consegna in modo che nessun pacchetto si nasconda dietro la corretta distribuzione del server. Esamina gli eventi di rifiuto della posizione come prova del flusso di lavoro: una richiesta di autorizzazione effettuata troppo presto necessita di una modifica della tempistica anziché presumere che la funzionalità di posizione sia interrotta.

Completa la chiave di volta con i pacchetti firmati, i canali aziendali scelti e una bozza dell'elenco. Aggiungi controlli di compatibilità all'avvio e report su arresti anomali e utilizzo. Consegnare la checklist di rilascio in modo che un'altra persona possa verificare i percorsi di consegna, aggiornamento e ripristino per ogni client.