flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "christofer.dutz@c-ware.de" <christofer.d...@c-ware.de>
Subject AW: Opinions on best method here
Date Fri, 28 Jun 2013 14:52:39 GMT
I don't know if this is possible, but how about storing the patrol data in (eventually zipped
as Om mentioned) chunks and to make sure a patrol visits a "data-dump-point" where you can
uploas things using a Wifi Connection ... when talking about hundreds of MB I doubt that you
will have any sort of Service that can handle that amount of upstream in a reasonable amount
of time. So if your patrols for example start in the "headquater" and end there, I would implement
the application in a way that it Caches data and Uploads the stuff automatically as soon as
the upload Connection is available.

Another alternative would be to upload text data live and to add the binary Image, Audio and
Video data as soon as a bigger upstream is available.

Just my 50ct to this Topic.

Von: Thomas Wright [twright@yesco.com]
Gesendet: Freitag, 28. Juni 2013 16:24
An: users@flex.apache.org
Betreff: Re: Opinions on best method here

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

> 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
View raw message