rawmain
commented
2 years ago Ciao @GabrieleCicconetti
All'inizio non andavano, poi ho capito che l'errore era nell'SDK_VERSION, io avevo la 1.0.3 mentre doveva essere 1.0.2. Ok, errore mio
Il flusso di validazione del codice SDK Android/Kotlin attualmente in branch develop (1.0.3) non implementa il sync black_list_uvci in Validation Rules della prodrelease 1.0.2, ma prevede invece il fetch/sync CRL RevokeList/RevokedPass = revoked UVCI presenti come hash SHA-256 codificati base64 nei chunk scaricati da endpoint CRL (ved. Apiservice.kt).
CRL endpoint per status check & download chunk NON sono ancora utilizzabili da chiunque, ma solo da team ufficiale / utenti autorizzati. Pertanto, volendo effettuare ora attività di test/staging con codice corrente branch develop+feature & senza rompere il flusso di validazione, è ancora necessario impostare temporaneamente l'uso di mock JSON per CRL status e revokelist. Vedasi closed issue #65 .
Questo è p.es. il mock-chunk aggiornato, che uso per i test correnti. Riprende le 717 counterfeit/fraudulent UVCI entry attualmente in black_list_uvci Validation Rules + 1001 UVCI addizionali leaked.
Si implementa agevolmente per ottenere build-variant apprelease basate su codice develop+feature & con OK flusso validazione (sample).
- TEMP Mock in it-dgc-verificac19-sdk-android/sdk/build.gradle
release {
buildConfigField "String", "BASE_URL", "\"https://get.dgc.gov.it/v1/dgc/\""
buildConfigField "String", "BASE_URL_CRL", "\"https://gist.githubusercontent.com/rawmain/85ea0786ded9e4634ae13f467ef343ac/raw/42ad731d33d12442a98c0af1721673ae4df1f6e1/rvktest02.json\""
buildConfigField "String", "BASE_URL_CRL_REVOKES", "\"https://gist.githubusercontent.com/rawmain/85ea0786ded9e4634ae13f467ef343ac/raw/42ad731d33d12442a98c0af1721673ae4df1f6e1/rvktest02.json\""
buildConfigField "String", "SERVER_HOST", "\"get.dgc.gov.it\""
buildConfigField "String", "CERTIFICATE_SHA", "\"sha256/7cZJIDPacG8FS3pq6Mvxg+7yBDM/VYc2alOcbVe/e74=\""
buildConfigField "String", "SDK_VERSION", "\"1.0.3\""
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}- TEMP Mock in it-dgc-verificac19-sdk-android/sdk/src/main/java/it/ministerodellasalute/verificaC19sdk/data/remote/ApiService.kt
/** @GET("drl/check") */
@GET(BuildConfig.BASE_URL_CRL)
suspend fun getCRLStatus(@Query("version") version: Long?): Response<ResponseBody>
/** @GET("drl") */
@GET(BuildConfig.BASE_URL_CRL_REVOKES)
suspend fun getRevokeList(@Query("version") version: Long?, @Query("chunk") chunk: Long?, ): Response<ResponseBody>
- Come faccio a capire quando questa prima sincronizzazione è terminata visto che viene effettuata in automatico? La documentazione dice che bisogna inizializzare il workerManager ma in realtà non c'è bisogno. (correggetemi se sbaglio) Quindi non ho modo di mostrare all'utente uno spinner o cose del genere
Lato codice app/UI puoi monitorare tranquillamente i progress in funzione degli aggiornamenti dei valori in Preferences/PrefKeys - correlati alle varie attività/funzioni di fetch/download e sync (Validation Rules - KID/signer updates - CRL chunks download + DB reconciliation).
Pertanto, non ci sono problemi a mostrare l'ongoing dei fetch tramite variazione stringhe testuali per status aggiornamento e/o elementi grafici (e.g. develop branch del codice app/UI VerificaC19 prevede anche una progress bar per 'Aggiornamento dati e regole').
Per quanto concerne l'inizializzazione del workerManager, sta a te valutare come implementarla in funzione di codice tua app/UI (vedansi anche definizioni versioni WorkManager / targetSdk). L'importante è che ci sia l'allineamento base con le condizioni prodrelease per fetch/load, che attualmente prevedono :
-
Fetch/Sync ad ogni avvio app/UI
-
Periodicità Fetch/Sync non superiore a 24h
- se queste API non funzionano nel momento in cui l'SDK_VERSION cambia (immagino che quando uscirà la 1.0.3, la 1.0.2 non funzionerà più) dovrei aggiornare l'app ogni volta e quindi tenere sotto controllo l'SDK_VERSION giorno e notte??
In caso di rilascio/utilizzo vostra app/soluzione in scenari pub/produzione, dovrete ovviamente allinearla in funzione degli aggiornamenti prodrelease SDK/librerie, come peraltro richiesto anche dalle condizioni di conformità per app/soluzioni terze ex artt. 12-13 DPCM 12/10/2021.
In ogni caso il monitoraggio del rilascio aggiornamenti - che non sono mica quotidiani - di prodrelease SDK Android/Kotlin è abbastanza agevole, potendo monitorare le variazioni del release-tracker unitamente al controllo soglia APP_MIN_VERSION Android in Validation Rules.
Altrettanto agevole è l'effettuazione periodica di staging/test preliminari a nuovi rilasci, considerata la disponibilità pub anticipata di nuovo codice nelle branch develop e feature.
Soprattutto quando - in virtù dei DPCM - si conoscono pure le deadline di rilascio aggiornamenti prodrelease, vedasi implementazione entro 06/12 di variazioni per flusso validazione in SDK = controllo ulteriore scan-mode 2G/3G (SGP) e (salvo variazioni) anche logica CRL/DRL per filtri di esclusione, al posto dell'attuale controllo black_list_uvci.
GabrieleCicconetti
stale[bot]
Scusate l'ignoranza ma... Stavo provando ad integrare questo SDK e ho visto che in automatico vengono chiamate le api
fetchValidationRules()efetchCertificates(). All'inizio non andavano, poi ho capito che l'errore era nell'SDK_VERSION, io avevo la 1.0.3 mentre doveva essere 1.0.2. Ok, errore mio, ma le domande sono:1) Come faccio a capire quando questa prima sincronizzazione è terminata visto che viene effettuata in automatico? La documentazione dice che bisogna inizializzare il workerManager ma in realtà non c'è bisogno. (correggetemi se sbaglio) Quindi non ho modo di mostrare all'utente uno spinner o cose del genere
2) se queste API non funzionano nel momento in cui l'SDK_VERSION cambia (immagino che quando uscirà la 1.0.3, la 1.0.2 non funzionerà più) dovrei aggiornare l'app ogni volta e quindi tenere sotto controllo l'SDK_VERSION giorno e notte??
Mi sembra un pò una follia ecco perchè credo che mi stia sfuggendo qualcosa.
Grazie in anticipo per le risposte.