I'm way out of my area of expertise here, but isn't this a classic 'unreliable data transfer' problem? I thought that's why 'smart' downloaders were invented. They know how to detect failure and restart where they left off when given a chance.
And regarding total bandwidth, sometimes it is worth computing and sending deltas vs sending the entire data set. -Alex On 6/28/13 8:02 AM, "Lionel A. Pierre" <[email protected]> wrote: >Depending on how much work you want to do at the server vs on the mobile >device, two extremes I can think of are .... > >*-- Most work on the server:* consider each patrol as a collection of >records, or one object with an collection of images, a collection of voice >notes etc ... batch it all up and send to server with a VO object >describing it >so the server knows how to add it to the database ... here your >VOPatrolDescriptor might look like > >patrolID:int >patrollerID:int >etc... >photos:Array >voiceNotes:Array >etc... >attachedFile:String > >*-- Most work on the mobile:* You could post just the data first, creating >the record on the server, then upload each of the attachments to that >record one at a time. > >Both have their pros and cons, you could pick the best of each and make a >hybrid solution. But if your users are like mine, they will want both and >want to be able to choose which one based on their connection speed or >something like that. > >Sounds like a fun app to work with. > >Good Luck > >*Lionel* > >On Fri, Jun 28, 2013 at 10:24 AM, Thomas Wright <[email protected]> wrote: > >> Hi, >> Thanks for your responses. >> @OmPrakash, I could definitely try that, however, we are already >>expected >> to use the amfphp framework, so I'll be sending objects over as >>appropriate >> and according to the pre-specified Vo files, however, zipping might work >> for the images. And I can totally dig the bytearray with a marker. I >>think >> that is definitely something to do. thnx >> >> @Angelo, I haven't yet calculated the size of the data to be sent. The >> images and videos are both pre-compressed, but even at that they are >>still >> quite large files. One patrol may have up to 5 or 6 images ranging up to >> 200mb. The patrols themselves are minuscule, simple database entries >>only >> about 15 text fields long. >> We do have decent bandwidth, but at the same time, my app is not the >>only >> app hitting the servers, so it occasionally bottlenecks, but this has >>been >> an issue that's recently been mostly rectified, so there shouldn't be >>too >> much of a problem even with super large submissions. >> >> thanks for your input guys :) >> >> >> On Fri, Jun 28, 2013 at 12:58 AM, Angelo Lazzari >> <[email protected]>wrote: >> >> > Hi, just a couple points to let me think on: >> > how much data are we talking about? Did you calculate the average >>amount >> > of the data for a single patrol? Do you have a good server bandwidth ? >> > >> > Bye! >> > >> > Sent from my ? >> > >> > On Jun 28, 2013, at 1:30, Thomas Wright <[email protected]> wrote: >> > >> > > So I'm just finishing one of our many mobile apps. >> > > The last step here before release is to create a submission process >>for >> > > certain gathered informations. >> > > Here's the thing, the information submitted is a sort of patrol >>entry >> > with >> > > media attachments. >> > > So in any one given day, we have multiple patrollers keeping tabs on >> > > clients and landmark structures. >> > > After the patroller is done with their route they are to submit the >> > patrol >> > > information, which usually averages from 80 to 200 depending on the >> > patrol >> > > route. >> > > So I'm looking at 80-200 patrols, each with photos, videos, voice >> notes, >> > > and sometimes documents attached which all need to be submitted to >>the >> > > servers. >> > > >> > > My question is this - considering the scale of the submissions, and >>the >> > > possibility of having areas without network access as well as the >> > > likelihood of a failed submission, I'm considering three options, >>each >> > for >> > > different reasons, but I'd like to get a broader perspective of >> opinions. >> > > >> > > 1) Submit one at a time, keeping the database patrol entry in sync >>with >> > the >> > > media submissions, if it fails, I can quickly nix it and re-submit. >> > > >> > > 2) submit in chunks, maybe 10 at a time, with their respected >>media. If >> > > this fails, it will be a bit more difficult to clean up, but it >>"seems" >> > it >> > > would be faster, though I'm not sure. >> > > >> > > and >> > > >> > > 3) submit all of the patrol entries into the database with client >> > > information etc. Then, after a successful submission, use the >>returned >> > data >> > > to correlate which new record go with which pieces of media, and >>submit >> > all >> > > the media at once. >> > > I suspect that though this would be the easiest to code, I may end >>up >> > > having far more problems with it in practice. >> > > >> > > Thoughts? Ideas? Has anyone done anything similar? >> > > >> > > Much appreciation! :) >> > > -- >> > > *Thomas Wright* >> > > Software Engineer >> > > Extension: 1054 >> > > Office: [801] 464.4600 >> > > >> > > Corporate Division >> > > [email protected] >> > >> >> >> >> -- >> *Thomas Wright* >> Software Engineer >> Extension: 1054 >> Office: [801] 464.4600 >> >> Corporate Division >> [email protected] >>
