Italian Sincronizzare db SQLite tra dispositivi

[LucaMs]

Salve a tutti.

Sono finalmente e ufficialmente "licenziato"

Le domande che avrei da fare sono molte (purtroppo); in cambio, spero di poter aiutare anch'io qualcuno e magari postare codice utile alla comunità.

Premesso che ho cercato sul sito, non ho trovato una risposta ottimale e definitiva.

Quello che vorrei ottenere è "semplicemente" la sincronizzazione dei dati db SQLite della mia app installata su due smartphone, senza web, cloud o "astrusità" del genere

Chiaramente, malgrado esistano WiFi, BlueTooth e NFC, immagino che il mezzo più comune sia BT.

Insomma, come implementare la cosa? C'è qualche libreria/classe già bella e pronta (sia come mezzo di scambio dati es. BT sia proprio dal punto di vista di tabelle e campi).

Ovviamente, non è SOLO pigrizia, la mia, ma la necessità di abbreviare i tempi di sviluppo.

Vi ringrazio anticipatamente e buon lavoro a tutti.

 

[LucaMs]

Possibile che nessuno abbia dovuto affrontare questa situazione ed abbia suggerimenti?

 

[AlpVir]

Io dico la mia.
La questione è assai complessa. Se si tratta di copiare un db su un dispositivo in un altro dispositivo (e viceversa) la cosa si può risolvere facilmente. Ma non si tratta di "sincronizzazione". Mi spiego meglio.
Se, poniamo, tu nel dispositivo A, hai un record con registrato "Arezo" (e nel dispositivo B pure). Poi ti accorgi che hai sbagliato e correggi (in A) "Arezzo" ecco che i due db sono disallineati e diversi. Copiare A in B risolve - per il momento - il problema.
Ma se tu nel frattempo avevi in A un altro record "Torrino" e in B "Torino, ecco che perpetui l'errore "Torrino" in B, anche se originariamente in B avevi il giusto valore "Torino".
Simili problemi accadono se in A sono presenti record che non ci sono in B (e viceversa) e questo può essere causato da .... diciamo così ... degli INSERT o dei DELETE.
Se il sistema non lo prevede nativamente (e SQLite non credo che lo consenta) io vedrei come unica soluzione quella di memorizzare, in una apposito campo di una tabella separata, le istruzioni SQL che via via si vanno facendo. Del genere :
INSERT INTO TabVattelapesca (Nome, Telefono) VALUES 'Mario',"1234'
DELETE FROM TabVattelapesca WHERE ID=33
ecc. ecc.
Poi, quando si vuole fare la sincronizzazione si eseguono ad una ad una, nei tempi opportuni, le varie istruzioni SQL.
Bisognerebbe sottolineare la frase "nei tempi opportuni" perchè le istruzioni vanno eseguite una dopo l'altra in ordine cronologico. Ci sarebbe da aggiungere qualcosa circa la indispensabile bidirezionalità di questa sincronizzazione ma credo di aver messo troppa carne al fuoco e la finisco qui.
Come hai compreso tu stesso se viceversa il db risiedesse nel web tutto sarebbe risolto in un amen e non si parlerebbe di sincronizzazione.
Io ho affrontato questo problema molti anni fa per sincronizzare 2 magazzini in 2 città diverse. E l'ho risolto con molti mal di testa e - pensa un po' - la sincronizzazione avveniva tramite un floppy disk che veniva spostato da una città all'altra.

 

[djveleno]

Dico la mia con le esperienze precedentemente maturate su db dedicati alla vendita... La sincronizzazione di dati provenienti da da 2 db identici ma differenti (identici nel nome dei campi delle tabelle, differenti nei dati contenuti), avveniva tramite un server che, contenendo un db identico agli altri due, raccoglieva i dati e, successivamente rimandava le tabelle aggiornate. Ora, applicare questo sistema a due smartphone mi sembra abbastanza complicato, almeno per quanto riguarda la parte server esterno, ma, se entrambi gli smart eseguono operazioni sui db, non vedo altre strade.

 

[LucaMs]

Io dico la mia.
La questione è assai complessa. Se si tratta di copiare un db su un dispositivo in un altro dispositivo (e viceversa) la cosa si può risolvere facilmente. Ma non si tratta di "sincronizzazione". Mi spiego meglio.
Se, poniamo, tu nel dispositivo A, hai un record con registrato "Arezo" (e nel dispositivo B pure). Poi ti accorgi che hai sbagliato e correggi (in A) "Arezzo" ecco che i due db sono disallineati e diversi. Copiare A in B risolve - per il momento - il problema.
Ma se tu nel frattempo avevi in A un altro record "Torrino" e in B "Torino, ecco che perpetui l'errore "Torrino" in B, anche se originariamente in B avevi il giusto valore "Torino".
Simili problemi accadono se in A sono presenti record che non ci sono in B (e viceversa) e questo può essere causato da .... diciamo così ... degli INSERT o dei DELETE.
Se il sistema non lo prevede nativamente (e SQLite non credo che lo consenta) io vedrei come unica soluzione quella di memorizzare, in una apposito campo di una tabella separata, le istruzioni SQL che via via si vanno facendo. Del genere :
INSERT INTO TabVattelapesca (Nome, Telefono) VALUES 'Mario',"1234'
DELETE FROM TabVattelapesca WHERE ID=33
ecc. ecc.
Poi, quando si vuole fare la sincronizzazione si eseguono ad una ad una, nei tempi opportuni, le varie istruzioni SQL.
Bisognerebbe sottolineare la frase "nei tempi opportuni" perchè le istruzioni vanno eseguite una dopo l'altra in ordine cronologico. Ci sarebbe da aggiungere qualcosa circa la indispensabile bidirezionalità di questa sincronizzazione ma credo di aver messo troppa carne al fuoco e la finisco qui.
Come hai compreso tu stesso se viceversa il db risiedesse nel web tutto sarebbe risolto in un amen e non si parlerebbe di sincronizzazione.
Io ho affrontato questo problema molti anni fa per sincronizzare 2 magazzini in 2 città diverse. E l'ho risolto con molti mal di testa e - pensa un po' - la sincronizzazione avveniva tramite un floppy disk che veniva spostato da una città all'altra.

Hehehe il floppy... da 720kb?

Beh, si, so che la faccenda è complessa e, dotandomi di adeguati analgesici, dal punto di vista di campi, tabelle, etc. in qualche modo riuscirò a farlo.
Mi serviva più che altro un consiglio su come trasferire (anche se la domanda riguardava anche cosa, così da non scervellarmi inutilmente).

Immagino che BlueTooth sia la soluzione migliore, o no (dato che wifi è più veloce).

Poi potrei mettere un flag per tabella (o addirittura record) che indichi all'altro dispositivo una modifica effettuata.

Ritengo che questa possa essere una situazione frequente, per chi utilizza SQLite su dispositivi mobili Android, per questo pensavo che qualcuno...

Grazie mille per la risposta, un Like lo "spendo" volentieri (non credo siano limitati, no?)

 

[LucaMs]

Dico la mia con le esperienze precedentemente maturate su db dedicati alla vendita... La sincronizzazione di dati provenienti da da 2 db identici ma differenti (identici nel nome dei campi delle tabelle, differenti nei dati contenuti), avveniva tramite un server che, contenendo un db identico agli altri due, raccoglieva i dati e, successivamente rimandava le tabelle aggiornate. Ora, applicare questo sistema a due smartphone mi sembra abbastanza complicato, almeno per quanto riguarda la parte server esterno, ma, se entrambi gli smart eseguono operazioni sui db, non vedo altre strade.

Non vorrei mettere in mezzo terzi "aggeggi", un po' perché non sono aggiornatissimo (sigh) ma soprattutto per non creare difficoltà agli utenti.
Come ho risposto ad AlpVir, penso che uno scambio di informazioni tra le due app circa tabelle/record modificati, potrebbe essere sufficiente, anche se complesso. Vedrò di usare BT, anche se in questo momento nn ricordo la libreria b4a da usare, ma la troverò.

Grazie per la risposta.

 

[luke2012]

Io ti consiglio per esperienza, che se prevedi una situazione di un'app con un db condiviso tra 2 o più smartphone, la soluzione migliore è quella di orientarsi verso un db come MYSQL.
Se cerchi trovi degli ottimi Tutorial per la connessione a MySQL.

 

[AlpVir]

Ma, se ho ben capito, LucaMs NON desidera che il db circoli per il web e, sempre che non prenda una cantonata, il pur ottimo mySQL non gira in uno smartphone. La sincronizzazione avverrebbe avvicinando i 2 smarphone e collegandoli via BT e sarebbe una sincronizzazione bidirezionale.

 

[LucaMs]

Ma, se ho ben capito, LucaMs NON desidera che il db circoli per il web e, sempre che non prenda una cantonata, il pur ottimo mySQL non gira in uno smartphone. La sincronizzazione avverrebbe avvicinando i 2 smarphone e collegandoli via BT e sarebbe una sincronizzazione bidirezionale.

Il db fà già parte dell'app ed è SQLite, perfetto per il mobile ma non solo!

AlpVir, hai capito perfettamente, vorrei evitare internet, per vari motivi (sicurezza-evitando criptazioni etc e, soprattutto, evitare agli utenti di doversi connettere: può non essere sempre possibile farlo e in Italia è ancora un costo non indifferente).

La verità è che immaginavo che molti che hanno iniziato a sviluppare per smartphone (io da qualche mese!), avessero già affrontato questa situazione, credo sia comune, se dietro un'app c'è un db. Se la tua app la comprano più persone in famiglia, la sincronizzazione dei dati... etc...

Ora non ricordo se ho messo questo "SOS" anche nel forum "inglese" (spero di si ), più frequentato.

Altrimenti dovrò sudare un po' e fare qualcosa sia con Wifi (direct?) che con BT e adattare il db al mio scopo.

Vi ringrazio per l'attenzione e le risposte.

 

[LucaMs]

Se io leggessi il "Similar threads"...

http://www.b4x.com/android/forum/threads/sqlite-e-condivisione-dei-dati.17043/

 

[djveleno]

Il thread a cui fai riferimento no fa altro che duplicare i suggerimenti che hai già avuto, in pratica, il WiFi direct prevede l'allacciamento di 2 apparati, se ne hai 3 0 4? In BT è più o meno la stessa cosa... in più, sincronizzare i dati tra 2 db, chi lo fa? l'apparato A o B? O entrambi dovranno avere la possibilità di collegarsi tra loro? Mi sembra che, teoricamente, l'app non sia impossibile da realizzare, ma in pratica credo sia abbastanza difficoltoso non ricorrendo ad un db serve esterno.

 

[LucaMs]

Il thread a cui fai riferimento no fa altro che duplicare i suggerimenti che hai già avuto, in pratica, il WiFi direct prevede l'allacciamento di 2 apparati, se ne hai 3 0 4? In BT è più o meno la stessa cosa... in più, sincronizzare i dati tra 2 db, chi lo fa? l'apparato A o B? O entrambi dovranno avere la possibilità di collegarsi tra loro? Mi sembra che, teoricamente, l'app non sia impossibile da realizzare, ma in pratica credo sia abbastanza difficoltoso non ricorrendo ad un db serve esterno.

Spero che tu abbia torto, circa la tua ultima affermazione, hehehe.

La mia app è relativamente semplice, due dispositivi connessi sono praticamente il massimo! E poi la sincronizzazione/allinemento non dev'essere istantanea, mi basta che una volta che venga modificato il db di un dispositivo, venga "consigliato vivamente" di allineare i dati con l'altro, magari rendendo attivo un tasto apposito solo quando ciò (la modifica) avvenga. Una sorta di trigger

Grazie DJ

 

[maxware]

Secondo me senza un db centrale la vedo durissima .. e poi dipende da cosa devi allineare
supponiamo la giacenza di un articolo
dispositivo 1 imposta giacenza di un articolo = 10
dispositivo 2 imposta giacenza dello stesso articolo = 20
quale e' quella giusta ? 10 o 20 , mi viene da pensare quella che ha la modifica piu' recente rispetto all'allinemante , ma nemmeno cosi' e' giusto perchè se la modifica della giacenza non la faccio nel momento corretto ma dopo per qualsiasi motivo risulta sballalto
Mamo

 

[LucaMs]

Secondo me senza un db centrale la vedo durissima .. e poi dipende da cosa devi allineare
supponiamo la giacenza di un articolo
dispositivo 1 imposta giacenza di un articolo = 10
dispositivo 2 imposta giacenza dello stesso articolo = 20
quale e' quella giusta ? 10 o 20 , mi viene da pensare quella che ha la modifica piu' recente rispetto all'allinemante , ma nemmeno cosi' e' giusto perchè se la modifica della giacenza non la faccio nel momento corretto ma dopo per qualsiasi motivo risulta sballalto
Mamo

 

[LucaMs]

eh, si, nn è facile, ma fattibile, basta scervellarsi un po'. Lo faccio mentre scrivo.

Nell'esempio che hai fatto, chiaramente una giacenza presuppone un oggetto fisico esistente (articolo di magazzino).

E' chiaro che se l'utente A modifica la giacenza (con un movimento "datato") lo fà a seguito di un'operazione fisica sull'articolo (vendita?). Certo non lo vende, se non ce l'ha! Non è che se legge nel suo db "art x qtà 1", inserirsce il movimento di vendita... vabbè, sto sragionando hehehe

Cmq, per essere ancora più chiaro, la mia app non è altro che una delle tante che si occupano di shopping (e sarà sicuramente peggiore, soprattutto, ma non solo, dal punto di vista estetico: pensa quante ne venderò ).

Quindi, mi serve che se la mogliettina fà la spesa o getta l'involucro del pacco di pasta (scarico), se il maritino fà la spesa 2 giorni dopo, sappia che la pasta è finita e deve comprarla (fatta una lista remember per qtà = 0).

Quindi, ripeto, l'allineamento non dev'essere necessariamente immediato.

Il punto principale, visto che di mobile conosco pochissimo, è anche il mezzo (BT-Wifi). Ho letto sul sito ma tutto troppo frettolosamente (tempus fugit, sigh). Mi pare che ci siano diverse librerie per questi scopi. Devo solo, con pazienza, rileggere quanto messo nei segnalibri del mio browser.

Grazie ancora a tutti per l'interessamento

 

[arenaluigi]

Ciao LucaMs,
hai poi trovato la soluzione migliore ?
Io devo implementare questa caratteristica, perchè avrò uno smartphone che sarà il master, scarica dei dati dal db remoto, poi gli altri smartphone dovranno collegarsi al master e scaricare il db in locale.
A fine giornata ogni smartphone, si ricollegherà con il master per passargli i dati lavorati, poi il master li invierà al database remoto.
Ho intenzione di utilizzare la wireless.

 

[LucaMs]

Ne ho pensate molte.

L'ideale, non penso ci siano dubbi, sarebbe che ogni dispositivo si connettesse al db centrale per qualunque operazione (bloccando anche il db o almeno le tabelle utilizzate).

Sono ancora indeciso se pubblicare la mia app senza questa funzionalità (importantissima, però); ma tanto, è un genere di app che è già molto presente sul Market.

Dato che il database alla fine sarà leggero anche con migliaia di record, potrei fare scaricare esso completamente, tramite FTP, se contiene modifiche più recenti.

Non è possibile (non senza impazzire) lasciare che un utente svolga il suo lavoro su una copia locale del db senza che immediatamente lo carichi su un server (db server o ftp che sia).

La wireless era stato il mio primo pensiero, più precisamente pensavo al wifi-direct, ma mi hanno giustamente fatto notare che i due utenti potrebbero poi trovarsi in città diverse.

Quindi: o db su un server, utente si connette, blocca il db durante l'uso oppure, quando avvia la propria app, questa verifica in FTP se il db ha subito modifiche rispetto al suo locale e se lo scarica.

 

[arenaluigi]

Io userò la wireless, attraverso tethering.
Gli smartphone slave non hanno nessuna possibilità di collegarsi in remoto, l'unica posto dove possono sincronizzarsi è lo smartphone slave.

 

[LucaMs]

eh ma dovrebbero farlo ad ogni loro operazione, questo è il punto critico, non a fine giornata (poi il tipo di connessione è secondario).

Insomma, i db devono essere "allineati", come si usa dire

 

[arenaluigi]

Io non ho questo problema, ognuno lavora dei propri dati, e sincronizza solo i suoi dati, che hanno priorità su tutto. Non ci sarà mai la situazione in cui due smartphone utilizzano gli stessi dati.