6 Replies Latest reply on May 13, 2009 8:51 AM by EvolvedDSM

    Data binding best practice on updating data


      I have an ArrayCollection contained in my Model, which is bound to a DataGrid which gets updated via remote calls every 10 minutes. The issue with this is that when my remote call returns, I create a new ArrayCollection from the returned data and assign it to my bound ArrayCollection. When doing this, the DataGrid treats this as all new data, and I loose my selectedItem, and any sorting that was specified before the call.


      So with that said, what are the best practices when binding data which will get updated frequently without user interaction. Would I really have to loop over my bound ArrayCollection and compare against the remote results for changes, then update the ArrayCollection instead of creating a new one?


      Seems like this would cause a performance issue (especially if the arrays are large), and also cause me to have to write some type of compare() method on the objects in the ArrayCollection to detect if data has changed and needs to be updated on the bound array.


      Just wanted to get some suggestions on this, as it looks like it would be pretty common to update bound data in this manner.

        • 1. Re: Data binding best practice on updating data
          EvolvedDSM Level 2

          Bringing your selectedItem back is fairly simple so long as the record data isn't modified or deleted when your remoteObject calls in the new set of data to the AC.


          Before setting your arrayCollection to the new dataset result from your remoteObject, establish your selectedItem as an object.


          var selObj:Object = datagrid.selectedItem; // captures your currently selectedItem as an object to reference later on in your new AC

          ... call your new ac here ...

          ... once the new ac is set and the datagrid updates ...

          var oldIndex:int = ac.getItemIndex(selObj); // gets the index position of our previously selectedItem

          datagrid.selectedIndex = oldIndex; // sets the datagrid's selected Index to the index of our saved object in the ac.



          As for sorting, I'm not sure if you can use the sort and sortField properties of the AC to capture previously sorted data.  When I need data to be updated automatically, I use LCDS with a dataservice which keeps my data updated in realtime (as best as LCDS can define this).  Otherwise, if data is not needed to be updated constantly, I can use remoteObject calls to updated my data source and then use arrayCollection properties addItem(), setItemAt()/itemUpdated(), and removeItemAt() to make the data appear in my ac record set the same as my database record set.



          Hope this helps.  The code is from a project I recently finished so it should be working, but you may need to make your own adjustments to work best for you!

          • 2. Re: Data binding best practice on updating data
            Barna Biro Level 3

            Hi there,


            I don't see a problem in the way you are doing it now. Regarding the "settings get lost", well, why don't you simply store any sort settings and store the index of the selected item and update the view once the new data is added? I think that would be the most logical thing to do.


            With best regards,

            Barna Biro

            • 3. Re: Data binding best practice on updating data
              ApoPen Level 1

              I could save the sort settings, but saving the index wouldn't work if new data is added hence making the saved index invalid. I would probably have to get the selectedItem before the timed refresh, update the bound array based on the remote call, then loop again to set the selectedItem again (comparing on a unique field in the object). Just seems like a little bit of overhead.


              And yes the other option is to use LCDS, but at the moment, I can't use this (next release).

              • 4. Re: Data binding best practice on updating data
                EvolvedDSM Level 2

                It's a questionable practice of setting a timed event to refresh data, especially if multiple clients are looking at the same record set and are making different changes to possibly the same record.  If LCDS isn't an option for you, I suppose this is your only choice, but you are bound to get a conflict eventually, especially if you are using such a large margin of time before refresh (10 min).


                Anyway, I still think you can use my code to keep your selectedIndex so long as the selected record wasn't modified or removed.  If not, GL!

                • 5. Re: Data binding best practice on updating data
                  ApoPen Level 1

                  In my case, the data is read only, so there shouldn't be an issue with corruption of the data on the server.


                  Unfortunatly, the selectedIndex, could possibly have been altered on the server side. Oh well, was worth a shot

                  • 6. Re: Data binding best practice on updating data
                    EvolvedDSM Level 2

                    Hmmm.... well I think if your records all have a unique identifer (something like an ID that never changes or is replaced when a record is deleted) you may be able to capture the record according to the ID before you refresh your AC, and then do a search on your AC for the same ID.


                    That's the only thing I can think of if my code above doesn't already accomplish it.  I'm not 100% certain as to what parts of the record an object uses to compare it as a match in the AC.


                    For instance, if we capture your selected record as an Object, but then some of the values of that record change (excluding your unique identifier),  could the ac.getIndexAt(Object) still find the ID as a match and assume thats the same record?  Just work with it before giving up!