flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wright <twri...@yesco.com>
Subject Re: Opinions on best method here
Date Fri, 28 Jun 2013 16:21:27 GMT
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 <twright@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 <aharui@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" <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
>> >>
>>
>>
>
>
> --
> *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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message