Scan diretto

[ghost]

Feature description

Buongiorno, vorrei suggerire la possibilità di valutare l’implementazione di recepire il qrcode senza aprire la fotocamera ma direttamente da scanner del dispositivo su cui è installata l'app.

Problem and motivation

Molti dispositivi che già leggono ad esempio i codici dei biglietti di ingresso potrebbero sfruttare lo scanner del dispositivo senza dover passare dalla fotocamera. Noi ad esempio usiamo questi terminali https://www.zebra.com/it/it/products/spec-sheets/mobile-computers/handheld/tc21-tc26.html già dotati di scanner ma dobbiamo comunque inquadrare il qrcode della certificazione verde con la fotocamera perché ad una scansione tramite scanner l'app VerificaC19 non risponde. Grazie e buona giornata

Is this something you're interested in working on

No

[Enrico204]

Se lo scanner è in grado di leggere i QR code (leggendo velocemente vedo solo "codici a barre", ma sul datasheet potrebbero esserci maggiori informazioni) in teoria è possibile, ma bisogna scrivere del codice a supporto usando i rispettivi SDK. Poiché non credo che si voglia supportare un numero enorme di SDK di vari produttori su questo progetto, io penso che sia meglio per voi fare un fork e integrare l'SDK del vostro scanner direttamente nella app

(non esiste un set di API standard per gli "scanner" che io sappia, al contrario delle fotocamere - dunque non c'è un modo facile per implementare questa cosa per tutti)

[ghost]

Lo scanner in questione legge sia 1D che 2D Per il resto purtroppo non so perché non mi intendo di programmazione. So però che l'app che utilizziamo per la lettura dei biglietti recepisce direttamente dallo scanner attivato dal suo tasto di scansione e funziona su parecchi tipi di scanner senza dover segnalare prima allo sviluppatore su quale marca si vuole usare.

[astagi]

Forse la PR #133 potrebbe aiutare in questa cosa @cadaniele ?

[NicholasBrunetto]

Attualmente la PR #133 fa riferimento ad un caso di invio di un intent con action e category predefinite ed un extra di tipo stringa con nome predefinito. Da quello che so, in base ad alcuni test che ho effettuato, le stringhe action e category sono customizzabili su diversi tipi di dispositivi scanner professionali, fra cui quelli Zebra indicati da @cadaniele. L'extra di tipo stringa ha però un nome non customizzabile sugli scanner Zebra, perciò la PR richiederebbe modifiche al valore predefinito (documentazione degli intent Zebra: https://techdocs.zebra.com/datawedge/6-3/guide/output/intent/). Questa modifica si potrebbe fare da codice selezionando il nome in base al valore del campo Build.BRAND, oppure aggiungere delle impostazioni nell'app di VerificaC19 con la possibilità di modificare le stringhe. La seconda opzione è più flessibile ma non so quanto sia ideale per utenti non esperti. Per la prima opzione si dovrebbero anche considerare altri casi particolari, come potrebbero essere gli scanner Honeywell o altri, ma è sicuramente una strada più semplice rispetto all'integrazione di diversi SDK in base al tipo di device.

[ghost]

Forse la PR #133 potrebbe aiutare in questa cosa @cadaniele ?

@astagi mi spiace ma tecnicamente non ho le competenze per valutare l'implementazione perché sono solo un utilizzatore finale. Però l'issue #127 in cui si fa riferimento alla PR #133 pare proprio dare questa possibilità. Parla di una funzione sfruttabile da vari dispositivi tra cui anche gli Zebra.

[acaliaro]

Attualmente la PR #133 fa riferimento ad un caso di invio di un intent con action e category predefinite ed un extra di tipo stringa con nome predefinito. Da quello che so, in base ad alcuni test che ho effettuato, le stringhe action e category sono customizzabili su diversi tipi di dispositivi scanner professionali, fra cui quelli Zebra indicati da @cadaniele. L'extra di tipo stringa ha però un nome non customizzabile sugli scanner Zebra, perciò la PR richiederebbe modifiche al valore predefinito (documentazione degli intent Zebra: https://techdocs.zebra.com/datawedge/6-3/guide/output/intent/). Questa modifica si potrebbe fare da codice selezionando il nome in base al valore del campo Build.BRAND, oppure aggiungere delle impostazioni nell'app di VerificaC19 con la possibilità di modificare le stringhe. La seconda opzione è più flessibile ma non so quanto sia ideale per utenti non esperti. Per la prima opzione si dovrebbero anche considerare altri casi particolari, come potrebbero essere gli scanner Honeywell o altri, ma è sicuramente una strada più semplice rispetto all'integrazione di diversi SDK in base al tipo di device.

Ciao Nicholas concordo con te. Una volta che è stato fatto il merge del tuo codice, potrei implementare io la parte Zebra Alessandro

[lleoncavallo]

Non è strettamente necessario nel senso che dal punto di vista tecnico è a mio avviso sufficiente avere un entry point; un wrapper è sempre implementabile esternamente da parte di un integratore. Ci siamo chiesti se includere già diversi supporti per Zebra, Honeywell, Datalogic ma non ci piaceva proporre soluzioni specifiche per alcuni produttori (i più importanti) penalizzando i più piccoli. La soluzione implementata da Nicholas è democratica e con un costo molto limitato permette l'implementazione di diverse soluzioni. Tutto dipende dall'impostazione che si desidera dare all'applicazione. Se si considera di valore dare un supporto nativo a Zebra/Honeywell etc... si potrebbe pensare a rendere configurabili gli identificatori di ACTION, CATEGORY ed EXTRA nel contesto di un mini SDK della App o mediante un classico approccio a file di configurazione. In questo modo sarebbe semplice adattare la app a diversi produttori di lettori. Potrebbe essere un approccio interessante a mio avviso. I clienti Zebra dovrebbero solo caricare un file di configurazione in una posizione specifica del file system ed installare la app di verifica dallo store.

[ghost]

@astagi ho visto che è stata rilasciata la versione 1.1.2 ma almeno per quanto riguarda il dispositivo Zebra TC21 la scansione da scanner non funziona ancora, ma non so è stata implementata per altri dispositivi. A questo punto rinnovo la richiesta (che farà storcere il naso a qualcuno ma per me è meglio percorrere anche altre alternative) che il team di sviluppo valuti la possibilità di emulazione tastiera con l'override della funzione di gestione pressione tasti del layout per evitare il problema del campo di testo.

[astagi]

@cadaniele corretto, non è stato implementato niente su quel lato. Come già risposto (anche privatamente ad alcuni) non ho potere di azione su determinate scelte, ho messo le PR in review a chi di dovere. Come saranno gestite e le decisioni prese in merito purtroppo non dipenderanno direttamente da me, sto insistendo perché vengano gestite le PR aperte e riportando tutto al team che se ne occupa, restiamo in attesa di una risposta, ci sono molte cose in priorità che prendono il sopravvento.

[ghost]

Certo immagino che abbiano il loro bel da fare. È anche per quello che proponevo una strada alternativa che magari ha un impatto diverso sullo sviluppo e possa magari vedere la luce prima. Purtroppo ci viene chiesto di fare dei controlli che diventeranno sempre maggiori ma non possiamo sfruttare a pieno la tecnologia. Grazie

[ghost]

Non ci sono novità su implementazioni per la lettura dei QR code senza usare la fotocamera?

[ghost]

Nessuna novità? Continueremo solo ed esclusivamente ad inquadrare i QR code? Grazie

[rawmain]

Ciao @cadaniele

Nessuna novità? Continueremo solo ed esclusivamente ad inquadrare i QR code?

Come puoi vedere dalle attività in active branches e PR, non ci sono evidenze pub di aggiunte/variazioni supporto 2D barcode reader per il prossimo rilascio iOS & Android di VerificaC19 (che avverrà comunque prima del 6 Dicembre).

Tuttavia, in virtù del DPCM 12/10/2021, che ha autorizzato il rilascio del DGC-SDK Android/Kotlin & definito anche in artt. 12-13 requisiti/conformità per suo uso in app/soluzioni terze, alcuni fornitori/vendor hanno già rilasciato soluzioni conformi - vedasi p.es. Datalogic con Verifica GP per i suoi terminali manuali Memor.

Prova a verificare con fornitore/dealer se ora - considerando l'approssimarsi delle nuove disposizioni - vi siano variazioni/novità per i terminali Zebra TC21/TC26. A fine Ottobre s'era comunque intravista una repo terza per integrazione controlli validazione con supporto barcode reader Zebra, per cui non è escluso che ora vi possano essere soluzioni anche per tali dispositivi.

[ghost]

Grazie Peccato che non possa essere gestito nativamente da VerificaC19 così da escludere ogni possibile criticità sulle tempistiche di aggiornamento da parte di terzi sviluppatori

[ghost]

@rawmain ne approfitto della tua disponibilità e preparazione Come avrai già probabilmente letto nei vari commenti qui sopra io sono solo un utilizzatore finale e non ho le competenze per proporre una PR, ma utilizzo una app che ha una caratteristica veramente comoda che permette di utilizzare il tasto fisico del dispositivo per effettuare la scansione del QR e passare il dato all'app del controllo biglietti del teatro. Questa app non ha un campo dove c'è da sincerarsi di essere per poter recepire la scansione ma basta che sia semplicemente aperta in primo piano, quindi non andrebbe neanche rivista la grafica di VerificaC19. Ho chiesto a chi ci ha fatto la nostra app e cito testualmente "è una emulazione tastiera ed è stato fatto l'override della funzione di gestione pressione tasti del layout". Qualcuno di voi potrebbe predisporre una PR con questa funzione per fare sì che possa esserne valutata l'implementazione? Grazie

[rawmain]

Ciao @cadaniele

Ho chiesto a chi ci ha fatto la nostra app e cito testualmente "è una emulazione tastiera ed è stato fatto l'override della funzione di gestione pressione tasti del layout". Qualcuno di voi potrebbe predisporre una PR con questa funzione per fare sì che possa esserne valutata l'implementazione?

Quanto chiedi è già previsto nello scope della citata PR #133 (pending-review da 9 Settembre n.d.r.), che integra appunto codice/commit di base, onde implementare il passaggio diretto della stringa HC1 qrCodeText.

Per il tuo caso richiede solo le modifiche specifiche/necessarie per supporto dispositivi Zebra / Datawedge intent, come indicato nei comment-roll della PR & di questo thread.

Pertanto, considerato che :

1. Le PR terze - proponenti modifiche non di fix e/o correlate a use-case minoritari - finiscono comunque in coda open/pending-review & senza definizione di vincoli/priorità per tempistica di loro gestione.

2. Il DPCM 12/10/2021 prevede minimi requisiti di conformità per sviluppo & utilizzo autorizzato di verifier-app terze/personalizzate.

3. Tempi/costi di implementazione & mantenimento/aggiornamento app personalizzata per tuo caso sarebbero ridotti al minimo, in virtù di disponibilità codice (repo ufficiali app/SDK/decoder + PR#133 + codice/sample Zebra) + possibilità di procedere da semplice fork da app/UI VerificaC19 (refactoring appID/package name e cambio logo/stringa nome app).

in assenza anche di app specifica & fornita da vendor/provider dei tuoi scanner, suggerirei di sondare/valutare la disponibilità in merito (anche per aggiornamenti) p.es. di chi già sviluppa/segue le vostre app.

[ghost]

Grazie Potrei sbagliarmi ma quella PR mi pare abbia un approccio diverso rispetto all'emulazione di tastiera che varrebbe per qualsiasi dispositivo senza ulteriori interventi. Comunque grazie e chiudete pure questo thread

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.