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!
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,
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).
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!
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
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!