@ClintStLaurent said:
StyleClass??? No idea what you're trying to use. Is that an iOS thing you're trying to use at the platform-agnostic shared layer?

It's a (poorly named and probably rarely used as a result) Xamarin.Forms thing. It's a property of VisualElement, defined as IList<string> StyleClass

I don't currently use it, but StyleTests.cs in the XF source code shows how it can be used. The MultipleStyleClassAreApplied() test is probably the most interesting one.

cc @ScottPendleton

@Khosrou - See https://forums.xamarin.com/discussion/comment/312458/#Comment_312458

In code behind casting the item selected is the solution

XAML:

< ListView
ItemSelected="EvetClicked">

Code Behind

  private void EvetClicked(object s, SelectedItemChangedEventArgs e)
{
try
  {
      var obj = (YourModel)e.SelectedItem;
         var ide = Convert.ToInt32(obj.IdYouWant);
      int IdInt Convert.ToInt32(ide);
  }
Catch()
  {
  }
}

@ScottPendleton said:
Just to be clear -- nobody had an answer for how to set the x:Name of a control that was generated from C# during page initialization.

Both @LuisDavidDelaCruz and I said to just instantiate the appropriate subclass and to use the resulting C# reference/variable. @LuisDavidDelaCruz was more explicit than me about x: name being the name of the variable.

In more detail, what happens with XAML is this:

Given the XAML in PageView.xaml:

    <Label
        x:Name="Geronimo"
        HorizontalOptions="Center"
        Text="Hello"
        VerticalOptions="Center" />

When it is built, a generated C# file PageView.xaml.g.cs (that you don't modify manually) is generated. That file contains:

public partial class PageView

and

private global::Xamarin.Forms.Label Geronimo;

and

Geronimo = global::Xamarin.Forms.NameScopeExtensions.FindByName<global::Xamarin.Forms.Label>(this, "Geronimo");

In PageView.xaml.cs (into which you put your own code), the remainder of the partial class called PageView is defined. In that class, you can use the Label Geronimo to do things such as:

Geronimo.Text = "Here we go";

So, what happens when x:Name is used in XAML is that a class is created (formed from two partial classes) that has a member variable with the specified name. So, if you work purely in C#, the equivalent is that you simply have a member variable with the desired name. In your particular scenario, using a collection will probably make more sense than using 32 named member variables.

@ScottPendleton said:
Is it automatic, or do we have to write code to accomplish all that?

See https://docs.microsoft.com/en-us/dotnet/api/xamarin.forms.listviewcachingstrategy?view=xamarin-forms

But note that there are differences between platforms. On UWP, RetainElement actually behaves the way RecycleElement would be expected to (I logged a bug for that long ago, but it doesn't look like it will ever be fixed). And on Android and iOS, the same code using RecycleElement does not result in precisely the same reuse of cells.

Note also that if you use Images in your ListView, you may need to do extra work, possibly including a third-party NuGet package (see https://github.com/luberda-molinet/FFImageLoading ) to avoid out-of-memory situations.

@StephenStchur - String formatting is like

<Label Text="{Binding SomeValue, StringFormat='{0:C}'}" />

Multi Value text in a label is as an example:

  <Label>
    <Label.FormattedText>
      <FormattedString>
        <Span Text="First" ForegroundColor="Blue" />
        <Span Text="Second" FontAttributes="Bold" />
      </FormattedString>
    </Label.FormattedText>
  </Label>

I avoid Device.StartTimer expect where it is really needed. What I see a lot of times is people start 15 individual timers and so they all start and run out of sync with each other.

At App level I use Task.Delay(1000) to create a loop that completes every 1 second. When it completes I raise a CLR event of "heartbeat". This provides a single, app-wide heartbeat event for synchronizing things. If one of your ViewModels should... check the server for updates let's say.. every 3 minutes then you count off 180 heartbeats. And it means all your ViewModels are working off the same heartbeat, not a different timer in each one adding mystery to why B happens a split second before A but D is after C like you expect.

I'm not sure if that helps explain why @developerdev2 would be starting a 1 second timer after the button click before starting a stopwatch - that's a mystery to me. I think he's trying to time how long a user clicks a given object... maybe... So the single heartbeat approach may not meet his needs: But I can't figure out what his needs are from that code.