Improve handling of updated data

[allisonmuise]

Hi Allison,

CP updates in this order:

1. CP queries all features for the main list of items
2. When a user selects an item, CP displays item details using the results from the all-features query used to create the main list display, not the current value of the item
3. CP highlights graphics of selected item by querying it again after zooming to get higher-res graphics, but results are only used for highlighting—the details of the item are not updated

If the user chooses to go back to the main list, CP queries all features for the main list display of items again.

CP does not do dynamic updates. We could enhance the app by hooking into the automatic refresh cycle that the map is using.

There is something that I think that we should change to support faster-changing data sets, however: The app should update the item details using the results of the higher-res graphics query. And the item details display should wait for these results before displaying the details to avoid a confusing flash of potentially obsolete values. This is less than a day’s work, but I think that it’s important: The longer the time gap between displaying the main panel and jumping to any one of its items, the more the item details will be out of date.

Mike

[allisonmuise]

Note: Sajit's testing showed that the app appeared to be pulling in cached values on load. A browser refresh did not reliably pull in updated content.

[MikeTschudi]

I was getting the same result with my browser debugger open and browser caching turned off.

Started branch support-faster-changing-data with a commit containing a cache-breaker for the main list query.

[allisonmuise]

@MikeTschudi Could you take a look at this for 7.1? Please install into the develop branch and devtopia when ready. Code freeze is Feb 14.

[allisonmuise]

@CTLocalGovTeam Would you be able to take a look at this issue for 7.1? I've merged in Mike's branch with the cache-breaker. The remaining work is to ensure that updated data is retrieved when browsing the app.

Per Mike: 1) Update the home page graphics with whatever is retrieved from the high-detail query. 2) Maybe hook into a feature layer's update or refresh-tick events to update layer contents.

The use case that prompted this was one where the app was being used to display election results. The data source was updated periodically, but the details available for each feature reflected what was available at app load, not the data values at the time the details view was accessed for a feature/the list of features was opened/revisited.

If this work is not possible for this release (need PR by Feb 11), please let me know.

[ashishchoure]

@allisonmuise

Here is our understanding from the above comments :

1. We need to make sure that, always updated feature is fetched from the layer whenever a feature is selected.
2. If layer has refresh interval, the layer contents and features should be updated as and when the layer updates. (This includes adding/deleting new features in the feature list after layer refresh)

Please let us know if anything else is to be incorporated apart from the above mentioned functionalities.

[allisonmuise]

@ashishchoure This sounds right to me!

[ashishchoure]

@allisonmuise @MikeTschudi

We have analyzed this ticket and here is our approach to implement the same.

1. Feature Selection :

   • The current CSP app queries the selected feature (with the help of Object ID) only for fetching the selected feature geometry to highlight it on map.
   • Instead, we are planning to query the feature as and when feature is selected through the map or list and the updated feature will be used to show the item details and its geometry will be used to highlight the graphic.
   • During testing the latest code, we have found that even after adding cache-breaker code the queryFeature still returns the old feature instance. (The query response in fiddler shows the updated feature but somehow in the application the old feature instance is returned).
   • To overcome this we are planning to replace the queryFeature by queryTask function. This change will also take care of quantization issues which we faced in CrowdSource Reporter.

2. Layer's refresh interval :

   • If layer has refresh interval set, we will listen for feature layer's refresh-tick event and accordingly we will update the issue list.
   • However, the app will fetch the updated/added features only if the user is on item list screen.
   • If user is on item details screen and the refresh-tick event is fired, list will be updated once user traverses back to item list.

Please let us know if this approach looks good.

[allisonmuise]

@MikeTschudi Does this approach follow the work you understood to be necessary?

[MikeTschudi]

@ashishchoure, why, please, do you suggest delaying handling the refresh-tick event when the user is on the item details screen? If a user is viewing the details and new comments come in from the refresh-tick event, they are relevant. Only if the user is actively entering his/her own comment does it seem like new comments should be delayed.

Feature selection approach sounds good. (I wish that you didn't have to work around the JSAPI swallowing the feature update!)

[ashishchoure]

@MikeTschudi @allisonmuise

• The reason behind delaying refresh-tick was the comment form. If user is feeling the information and suddenly the contents refreshed then user will lose the information.
• However, we do agree to the point that the updated feature details and new/updated comments are relevant.
• To overcome this, we will restrict the update only if comment form is open.
• Regarding the workaround to get the updated feature, even after adding the timestamp to the queryFeature still the old feature instance is returned.
• In addition to the above point, we have faced some issues related to quantization with queryFeature in crowd source reporter. This is the reason we are planning to use Query Task.

[MikeTschudi]

@ashishchoure, thanks for the explanation; it all sounds good!

[allisonmuise]

@aparveen @LindsayThomas Want to test this with the elections data?

[aparveen]

@allisonmuise I will test it.

[LindsayThomas]

@allisonmuise Can you please confirm this repro scenario? (I am aware of the issue but I don't know the technical details)

Create an application using hosted feature layer for crowdsource polling In the web map - set the refresh interval to 0.1 on each layer configure the application with these layers, and a field that you will update Bring up the application

In another browser, bring up the webmap item, go to the data tab and update the field that you have configured in the application.

You should see the field that you are updating, updating the application side panel

(You can use any data to test this)

[allisonmuise]

@LindsayThomas I'm not sure.

@MikeTschudi or @ashishchoure can you confirm that this is a valid repro scenario.

[ashishchoure]

@allisonmuise @LindsayThomas

The above scenario sounds correct.

Here are the list of scenarios which we have considered while testing :

• The newly added feature should be added in the list.
• The deleted feature should be deleted from the list.
• The updated feature should be reflected in the list.

[aparveen]

Verified in devext.