ArcGISFeature.Attributes.Count is Much Lower than Expected

[TheKenerson]

Newbie question of the day. I am writing a simple data editor using Xamarin Forms .Here is my issue: In my sample, when I access a selected feature in my feature service, I get a count of 4 for my feature service and I am expecting a count of 49. 

The Count is displayed using the ArcGIS Feature.Attributes.Count Property.

So I can display and edit the attributes, but only a few of them. 

I have tried accessing other feature services from AGOL, and their counts are way off too. Its generally about 10% of the total number of attributes.

I think the data is okay as I can access/display/edit the same feature service in a webapp using REST with the JavaScript API I just cannot access the data in the .NET Runtime Xamarin Forms Application.

Anybody else come across this behavior?

[dotMorten_esri · Accepted solution]

Did you load the feature first? By default only a minimum set of attributes needed for rendering is requested from the server so you won't get the network overhead of downloading a bunch of attributes you might not ever see. Once you identify a feature and want to display it in the UI, you should "load" it first so that all the data is included:

if(feature is ILoadable)

    await ((ILoadable)feature).LoadAsync();

[TheKenerson]

Thank you. That was what i was missing. I'm new to the .NET API and i didn't know about it. Here is what i did and how i checked it. Maybe its helpful for somebody else.

public async Task LoadAsync_site(ArcGISFeature _feature)
{
Feature = _feature;

await Feature.LoadAsync();

//if the featurewas loaded successfully, you can see all attributes. Below is a test
if (_Feature.LoadStatus == Esri.ArcGISRuntime.LoadStatus.Loaded)
{

var A_value = Feature.GetAttributeValue("field_A");
var B_value = Feature.GetAttributeValue("field_B");
var C_value = Feature.GetAttributeValue("Field_C");

}

}

[dotMorten_esri]

I'm glad it worked out for you.

You don't really need the LoadStatus check. It's guaranteed to have succeeded - otherwise it would throw (so you might want to use try/catch instead)