We may be entirely going about this the wrong way, but we currently store the 'state' of the FeatureLayer by storing several of its properties on a wrapper class and then serializing that class. So, for FeatureLayers we store the data path, name, renderer json, labelling info, and definition expression as just strings/bools. On deserialization we create a new layer from the path and set all those stored properties back on the layer. One thing that is missing from our setup is the selection state for features.
One idea we had was to:
- Get selected features (featureLayer.GetSelectedFeaturesAsync())
- Determine the ID field for that feature table.
- If it's an ArcGISFeatureTable, then you can use the GlobalIDField property.
- If it's a ShapeFileFeatureTable, then it should always be "FID"?
- Unsure what to do if its GeoPackageFeatureTable.
- For each selected feature get the ID value from its attribute table using the ID field from step 2.
- Serialize this collection of string IDs alongside the other layer info.
- On deserialization build a QueryParameter with a where clause with something like $"Where {tableIDFromStep2} IN ({string.Join(", ", selectedFeatureIDs})"
- Query out those features and select them on the newly loaded layer.
The concerns for this setup are pretty minor, but worth mentioning:
- Are we identifying the correct field ID? The users are bringing in their own data sources, so can we be certain we are always getting the right key?
- We could end up storing/querying 100k+ features for large datasets if the user decides to select the whole map for some reason which could be costly and bloat the json file.
So, with that said, is this the intended way of doing this? Or is there a much simpler option I missed?