IOS 6

[m.dieugenio]

Ri-Apro il post in quanto il precedente è stato bloccato.

l'ultima risposta era
"Nella versione versione 12.0 abbiamo innalzato il timeout di connessione da 15 a 30 secondi per le DownloadFile asincrone."

Ma il problema non era nel download del file.
Come verificato in assistenza e documentato su internet iOs 6 ha ridotto il timeout di attesa a 15 secondi, in questo modo i sistemi di sincronizzazione funzionano solamente per applicazioni con bassa quantità di dati.

Il problema non è solo per il download in quanto:
- il client richiede al server un'elaborazione
Se il server non risponde entro 15 secondi in quanto l'elaborazione non sì è conclusa allora la connessione viene chiusa e nulla funziona più.

Era stato verificato in assistenza che esiste un parametro (da impostare su caravel) per aumentare tale tempo di attesa e che con la versione 12 di In.de lo stesso poteva essere gestito in autonomia.

PRima di passare alla versione 12 i miei progetti vorrei sapere se questa attività è ora gestibile.
Grazie

[mcdok]

interessa anche me

[g.lanzi]

In versione 12.0 è possibile specificare il timeout di connessione ID_TIMEOUT. Per ulteriori informazioni è disponibile una nota di rilascio http://doc.instantdeveloper.com/?ARTID=CC1A11F2-FA30-43A5-B45B-972D38A01D90.

[m.dieugenio]

Il documento parla solo di GETHTTP, il mio problema è relativo alla funzione Syncservice.query che una volta eseguito deve attendere la risposta del server prima di proseguire.

[g.lanzi]

Nel caso della Query il parametro non ha lo stesso effetto. Allo stato attuale se la query di sincronizzazione è troppo lenta per essere eseguita occorre procedere diversamente.

Ad esempio è possibile fare una richiesta HTTP al server (quindi configurabile con il timeout) per chiedergli di creare un file o un backup di un intero database SQLite.

A questo punto il server potrebbe rispondere con l'indirizzo del file da scaricare e da elaborare lato dispositivo.

Mi piacerebbe scrivere un articolo nel blog, su questo argomento.

[g.cassanelli]

Chiedo scusa, mi intrometto perché mi interessa: avevo fatto numerosissimi test ma ancora non sono in produzione ...

La domanda è: i 15 secondi di cui si parla per il timeout sono nella risposta alla singola chiamata, quindi se invio una richiesta e il server, tra elaborazione, selezione dei dati ecc. impiega più di 15" (ad esempio) cade la connessione... corretto ?
Se è così e non è possibile gestire il tempo di timeout una sincronizzazione reale sul campo non è gestibile in sicurezza a meno di certezza assoluta sulle dimensioni degli archivi (che a volte capita, ma non sempre).
Il problema è limitato a IO6 spero, cioé su Android e Win8 funziona ?
E qualcuno l'ha provato con dati "corposi" ?
Grazie

[m.dieugenio]

Io sono in produzione ormai da un pò di tempo con dati decisamente corposi, e su iOS5 non avevo problemi di timeout.

Con iOS6 il problema è esattamente quello dettagliato da cassanelli.
Fino ad oggi ho temporeggiato facendo si che il cliente non aggiorni i suoi iPad alla versione 6, ma ora (acquistando nuovi iPad) la situazione non è sostenibile...effettuare il dowgrade del Sistema Operativo è un'impresa oltre ad una dimostrazione di un software non aggiornato.

Ho segnalato il problema molto tempo fà ed ero fiducioso che la versione 12 ci avrebbe consentito di impostare tale parametro.
Se così non fosse direi che su iOS6 le applicazioni realizzate con INDE e basate su elaborazioni su dati corposi non sono gestibili.

[g.cassanelli]

Non è una bella prospettiva per sviluppare pensando a più piattaforme.... e su Android e Win8 ?

[g.lanzi]

Fortunatamente una soluzione è già disponibile. Anche se non è possibile specificare il parametro per la SyncQuery è possibile farlo per la GetHTTP, e le due funzioni non sono dissimili nell'utilizzo.

La GetHTTP torna una stringa, mentre la Syncservice.Query torna un recordset. Se ci troviamo di fronte ad una situazione nella quale determinate query possono essere molto lente, allora è sufficiente salvare il recordset in XML e rileggerlo lato dispositivo:
- usiamo una GetHTTP per chiamare l'applicazione con un determinato comando e con tutti i parametri necessari, aggiungendo anche il parametro "domain" per filtrare correttamente i dati
- nell'OnCommand dell'applicazione server basta leggere i parametri ed usare lo stesso codice che si sarebbe scritto nell'evento OnSyncQuery. Eventualmente è possibile richiamare proprio lo stesso evento invece di riscrivere il codice.
- una volta ottenuto il recordset basta eseguire una SendToBrowser(recordset.saveToXML())
- lato dispositivo sarà poi possibile creare un recordset a partire dalla risposta della GetHTTP.

Così l'implementazione è puntuale e non coinvolge il codice applicativo già scritto.

[m.dieugenio]

In realtà non si tratta di query molto lente bensì di tempi tecnici (per via della grossa mole di dati).
Supponiamo di dover riscrivere nuovamente questa parte della sincronizzazione con la GetHTTP; quando il client effettua la richiesta, lo stesso resta in attesa (come attualmente avviene per la syncquery) della risposta del server?

Grazie