|
Hi, after reading on-line documentation about Resuming Failed Downloads in Mobilink and Ultralite, I have got some doubts about how download failures are managed with UltraliteJ clients. I’m using UltraliteJ for Android. Synchronization will be over 3G channels, where connection failures are an issue. Does Ultralite + Mobilink detect and recover those partial downloads automatically? Otherwise, how could I control and deal with it programmatically? Thanks |
|
By default, if a synchronization fails, it is rejected and will be restarted on the next synchronization request as if the failed synchronization never happened. For HTTP and HTTPS the UltraLite C runtime will retry automatically to resume the sync to handle very short communication interruptions. A colleague of mine mentioned that if you specify synchronization parameters using a sync profile, you should be able to specify resume-able downloads or resuming a sync downloads (Unfortunately, the UltraLiteJ API does not expose a method to rollback the download). This would be used when there are longer communication errors. The ideal design would involve sync code that retried after communication errors combined with code to detect when the phone is out of coverage. Retries would use increasing time delays between retries and perhaps a max number of retries (in case the server is down, you don't want to kill the battery). 1
Just to clarify: the UltraLite C runtime retry is present on Android, and happens automatically when you call synchronize(), and was designed to handle the kind of short interruptions that mobile devices are prone to.
(29 Aug '11, 11:02)
Tom Slee
Thanks Philippe for your clear reply. Just a last question about "synchronization fail" concept. A fail is: * Any ULjException throws during synchronize() * SyncObserver returns true??
(30 Aug '11, 02:47)
David
Replies hidden
Yes and no. Downloads are only resume-able if a communication error took place. Other errors such as canceling the sync, download conflicts, etc will not result in a download being saved. Also, you really need the rollback download (which UltraLite for Android does not have - I put in a request for it) to have a complete solution otherwise once you have a partial download, you must continue to resume it and do no other syncs (i.e. different publications) until it resumes.
(30 Aug '11, 10:31)
PhilippeBert...
Comment Text Removed
Ok, again, an explanatory reply. Is there any public roadmap or versions planning for Ultralite on Android?
(31 Aug '11, 03:02)
David
Initially, we implemented the UltraLiteJ API as is used on BlackBerry since we felt this would be the most common subset. Some methods did not apply so they were left off, 1 or 2 were missed and we try to fix them right away. Additional UltraLite functionality not supported in UltraLiteJ is evaluated on a case-by-case basis and prioritized. We want to add it in a manner that does not make a mess of the existing API but as well takes into consideration that the same functionality may be added for BlackBerry simultaneously or at a later date. Summary: we track requests and strive to provide them as soon as possible based on release schedules and criticalness.
(31 Aug '11, 10:04)
PhilippeBert...
|
