Question

I am trying to get a StringElement’s ‘Value’ to update in the UI when I set it after already setting up the DVC.

e.g:

public partial class TestDialog : DialogViewController
{
    public TestDialog() : base (UITableViewStyle.Grouped, null)
    {
        var stringElement = new StringElement("Hola");
        stringElement.Value = "0 Taps";
        int tapCount = 0;
        stringElement.Tapped += () => stringElement.Value = ++tapCount + " Taps";

        Root = new RootElement("TestDialog")
        {
            new Section("First Section")
            {
                stringElement,
            },
        };
    }
}

However the StringElement.Value is just a public field, and is only written to the UICell during initialization when Element.GetCell is called.

Why isn’t it a property, with logic in the setter to update the UICell (like the majority of Elements, e.g. EntryElement.Value):

public string Value 
{
    get { return val; }
    set 
    {
        val = value;
        if (entry != null)
            entry.Text = value;
    }
}

EDIT :
I made my own version of StringElement, derived from Element (basically just copied the source code from here verbatim)

I then changed it to take a class scoped reference to the cell created in GetCell, rather than function scoped. Then changed the Value field to a property:

public string Value 
{
    get { return val; }
    set 
    {
        val = value;
        if (cell != null)
        {
            // (The below is copied direct from GetCell)

            // The check is needed because the cell might have been recycled.
            if (cell.DetailTextLabel != null)
                cell.DetailTextLabel.Text = Value == null ? "" : Value;
        }
    }
}

It works in initial testing. However I am not sure on whether taking a reference to the cell is allowed, none of the other elements seem to do it (they only take references to control’s placed within the cells). Is it possible that multiple ‘live’* cell’s are created based on the one MonoTouch.Dialog.Element instance?

*I say live to indicate cells currently part of the active UI. I did notice when navigating back to the dialog from a child dialog the GetCell method is invoked again and a new cell created based on the Element, but this is still a 1-1 between the element and the live cell.

Answer 1

For the main question:

Why does MonoTouch.Dialog use public fields for some Element options, and public properties for others?

I’ve been through the code, and I don’t think there’s a consistent reason for use of either.

The Dialog project was not part of the MonoTouch project initially – I don’t think Miguel knew how useful it was going to turn out when he started wrote and grew it – I think he was more focussed on writing other apps like TweetStation at the time.

I know of several people (including me!) who have branched the code and adapted it for their purposes. I would guess at some future point Xamarin might write a 2.0 version with stricter coding standards.

Taking references to live cells

For limited use you can do this… but in general don’t.

The idea of the table view is that cells get reused when the user scrolls up and down – especially in order to save memory and ui resources. Because of this is a long list, multiple elements might get references to the same cell.

If you do want to cache a cell reference then you probably should override GetCell() so that it never tries to reuse existing cells (never calls DequeueReusableCell)

Alternatively, you could try to change some code in the base Element class in order to find out if the Element has a current attached cell – this is what CurrentAttachedCell does in my branch of Dialog https://github.com/slodge/MvvmCross/blob/master/Cirrious/Cirrious.MvvmCross.Dialog/Dialog/Elements/Element.cs (but that branch has other added functions and dependencies so you probably won’t want to use it for this current work!)