I'm trying to solve an issue with uploading attachments (FeatureLayer.addAttachment) and an unreliable cellular connection on a tablet (Air 3.3 on Android, Flex API 2.5 online/offline app). At first, long uploads were receiving a fault (Stream Error) after 30 seconds on the device and yet would finish successfully on the server without further notifcation. This was solved with setting :URLRequestDefaults.idleTimeout = LONGER_THAN_30SEC. //FeatureLayer.requestTimeout was being ignored.
However, now I still have the edge case of the device losing connection before receiving a response from the server that the attachment was either successful or not (and with a long timeout, it just waits and waits because it never receives the response). The main issue with this is that if I re-send the attachment after assumed failure, it creates a duplicate record. In this scenario, I don't want the user to have to check to make sure the attachment is already there before re-sending either. This also really applies to FeatureLayer.applyEdits as well - just more likely to send correctly since less data.Possible solutions:
- Keep 30 second timeout and cancel the upload if timeout reached (There doesn't appear to be anyway to cancel the upload that I can find - there's no way to cancel underlying URLRequest).
- Make the app timeout roughly match the server timeout on the upload and assume if the app timeouts, then the server timed out and canceled the upload. I can't find a way to set that timeout - it doesn't appear that the "The maximum time a client can use a service:" setting in manager is adhered to for uploads. Is there another place to set this timeout that could be limited to just the FeatureService in question?
- Create a proxy service wrapping the rest api and check for duplicates before inserting new record.
- Create a proxy service handling the upload using Air's File.Upload (which can be canceled) and then calling rest API through the proxy.
- Query attachments for existing filename already there before submitting attachment (i think this may be best bet, but would rather prevent needing this extra call to server).
Does anyone have any suggestions or ideas on the best way to handle this? Is there something I'm missing?Thanks,Josh
