quick note on the AAC, I made it sound like it totally corrects everything. Even though the AAC rolls everything back, there is still a lot of damage control that has to be done mobile side - if that makes sense. It's mostly for the data within the AAC and it's correlate data on the server. But the coordination with the media files and submission of is a big clean-up job if a major fault were to occur. And that's the specific clean-up I was referring to. Perhaps, Alex, now that I'm thinking about this ... well ... ya, I'm going to have to think about this. I'll take a look at some of the smart up/down loaders out there. But considering this further, I may have to just build my own and implement Christofer's idea with a few twists.
On Fri, Jun 28, 2013 at 10:07 AM, Thomas Wright <[email protected]> wrote: > @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] > > -- *Thomas Wright* Software Engineer Extension: 1054 Office: [801] 464.4600 Corporate Division [email protected]
