You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by Thomas Wright <tw...@yesco.com> on 2013/06/28 01:30:17 UTC
Opinions on best method here
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
Re: Opinions on best method here
Posted by Thomas Wright <tw...@yesco.com>.
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 <tw...@yesco.com> 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 <ah...@adobe.com> 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" <li...@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 <tw...@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
>> >> <la...@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 <tw...@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
>> >>
>>
>>
>
>
> --
> *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
Re: Opinions on best method here
Posted by Thomas Wright <tw...@yesco.com>.
@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 <ah...@adobe.com> 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" <li...@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 <tw...@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
> >> <la...@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 <tw...@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
> >>
>
>
--
*Thomas Wright*
Software Engineer
Extension: 1054
Office: [801] 464.4600
Corporate Division
twright@yesco.com
Re: Opinions on best method here
Posted by Alex Harui <ah...@adobe.com>.
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" <li...@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 <tw...@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
>> <la...@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 <tw...@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
>>
Re: Opinions on best method here
Posted by "Lionel A. Pierre" <li...@medez.com>.
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 <tw...@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
> <la...@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 <tw...@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
>
AW: Opinions on best method here
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
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.
Chris
________________________________________
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
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
<la...@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 <tw...@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
Re: Opinions on best method here
Posted by Thomas Wright <tw...@yesco.com>.
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
<la...@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 <tw...@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
Re: Opinions on best method here
Posted by Angelo Lazzari <la...@gmail.com>.
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 <tw...@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
Re: Opinions on best method here
Posted by OmPrakash Muppirala <bi...@gmail.com>.
A couple of approaches of the top of my mind:
1. Try to zip the contents of the file into one file. Depending on how
the existing media is compressed (.jpg, etc.) you might not get a lot of
mileage out of zipping files. But if they are not already compressed, you
could save a lot of bandwidth. Best would be use ANEs to do the
compression.
2. Maybe you could open up a socket and push the bytes to a server. This
way, you could upload for a while, store a marker in the bytearray and
resume later if needed.
Not sure if it is possible, but maybe this could help.
Thanks,
Om
On Thu, Jun 27, 2013 at 4:30 PM, Thomas Wright <tw...@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
>