When users save a record in our apps I check if the feature can be updated, and if not I add the feature instead. In a recent app (100.5) we've noticed that if the user updates the (point) geometry canUpdateFeature is returning as false and triggering the creation of a duplicate feature in the geodatabase.
Is this the expected behavior? Should I be detecting an existing feature in another way?
Yes - not sure exactly why it was happening, but editing the geometry was triggering "false" on canUpdateFeature and was then being added as a new record by our app. Changing the extent of our .geodatabase file to cover the whole planet resolved the issue for us.
As far as I can tell neither the original geometry or the updated geometry were outside of the service's maximum extent which is what we were previously using for our offline .geodatabase extent... so still not sure what was up.
I've found out a little more from the team. When you take a .geodatabase offline with a target extent, any edits outside of it are considered invalid.
It sounds like what you're seeing isn't covered by the above rule, so I'd be interested to see what your replica's target extent and the service's full extent are.
It would also be helpful to understand what the edited geometry is when this is triggered.
Interesting - so would it be correct to assume that edits are considered invalid but new features can still be added? That would explain why those features were able to be saved as new features. It created duplicates, which was inconvenient, but that's better than not saving at all.
Previously we were using featureServiceInfo.fullExtent to define the limits of our replica... for this specific service that is defined as:
Full Extent:
This appears to be due to the new point being outside the replica extent. Not sure yet though because our users were definitely out inside the extent when editing field points and we got duplicate records.