@christofer thanks for your suggestion. This is something we've talked a lot about as well. It's definitely on the list of things to add.
@Lionel it has been pretty fun to work with. I like the idea of having both possibilities and/or some automatic configuration of both. Giving the user more control over the automatic functions is something these guys would love to. I'll have to jot this down. thanks :) @Alex thanks, yes. In fact, we've specifically designed an ArrayCollection/RemoteObject class [AdvancedArrayCollection] to handle the unreliable transfer problems. It coordinates its efforts with the server in such a way that if any sort of transfer error were to occur, everything that faulted gets rolled back both on the server and on the phone, making a clean break from the fault so it can be resumed without any consequences. I didn't write it, and it's actually beyond me how exactly it works. There's all these rules as to how one rolls data back, what calls to make in what order, how to structure the rollback - and much of it goes over my head. It's some sort of logic integrity based algorithm that makes the database and file calls in some particular order so as to minimize potential faults during the roll back. My boss said he had to buy a book specifically for it and barely understands it himself. lol One of the reasons I have such a restricted space to work in is actually because of the AAC and how it integrates with the server/database/amfphp and the vo files. We have a larger php/flex system running server side that coordinates everything - like a mother brain. So I have to work within her parameters or she'll kill the call. Thank you everyone, this has given me quite a lot to think about, and many new ideas to integrate. I appreciate all of the responses :) On Fri, Jun 28, 2013 at 9:21 AM, Alex Harui <[email protected]> wrote: > 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] > >> > > -- *Thomas Wright* Software Engineer Extension: 1054 Office: [801] 464.4600 Corporate Division [email protected]
