flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Opinions on best method here
Date Fri, 28 Jun 2013 15:21:15 GMT
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" <lionelp@medez.com> 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 <twright@yesco.com> 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
>> <lazzari.angelo@gmail.com>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 <twright@yesco.com> 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
>> > > twright@yesco.com
>> >
>>
>>
>>
>> --
>> *Thomas Wright*
>> Software Engineer
>> Extension: 1054
>> Office: [801] 464.4600
>>
>> Corporate Division
>> twright@yesco.com
>>


Mime
View raw message