flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wright <twri...@yesco.com>
Subject Opinions on best method here
Date Thu, 27 Jun 2013 23:30:17 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message