slodge / android.dialog Goto Github PK

I'm thinking of providing a new JSON module allowing elements like:

  new StringElement("Label", "Only Element in a Blank Section"),

to be declared something like:

  {
        'Element': 'String',
        'Properties':
        [
               "Caption": "Label",
               "Value": "Only Element in a Blank Section"
        ]
  }

This would be built using reflection - so more automagically extensible than the json in MT.Dialog.

The code would include options to bind properties and events like:

               "LayoutId": "@Resource:resource_name"

and Mvvm Binding (with MvvmCross format) like:

               "Value": "@Bind:{'Path':'PropertyOnViewModel', 'Converter': 'AConverter', ... }"

and:

               'Click' : '@Bind:{'Path':'TheCommand'}

This would provide a cross platform way of declaring UIs.... I might even have a go at a WindowsPhone.Dialog....

I would prefer not to use Android.Dialog

It feels like the namespace Android belongs to someone else....

I'd rather use something that can't cause a hideous clash at some point in the future...

Maybe MonoDroid.Dialog again?

Currently the resources for layouts are overriden using a LayoutId enumeration which is looked up in a hard-coded lookup map - enumeration to the string name of an Android ResourceId

This system uses context.Resources.GetIdentifier() to find the actual resource.

In the new version, we would:

• use a system of String LayoutId names
• use reflection to get the resourceId integer from the string

This would have the key advantages:

• it would allow people to register their own resourceids (this is currently "// TODO: figure out what context to use to get this right, currently doesn't inflate application resources")
• it removes the deprecated GetIdentifier mechanism

Use of this system would mean that lines like:

                    new StringElement("DialogListView Activity", (int)DroidResources.ElementLayout.dialog_labelfieldright)

would become:

                    new StringElement("DialogListView Activity", "dialog_labelfieldright")

One negative impact on this would be the use of string matching for the layoutids - I'm open to ideas on how to improve this - but the current new design is no worse than the existing one (which also uses string resource names)

This isn't actually a change to the API or linking of the Dialog at all.

I'd hope to provide Mvvm Bindings externally to the Dialog.

However.... I think this does require changes like #2

Currently the convertView situation looks buggy to me:

1. It appears that the type of view being reused isn't checked before reuse (I might be wrong on this - I haven't yet fully understood the code!)
2. When views are reused it seems that member variable updates and event subscription/unsubscription isn't fully handled in all cases

I think these current problems aren't that important for small dialogs, or for dialogs used in one-pass update/refresh cycles.

However, for Mvvm - where individual fields will be updated - then this seems very important to me.

Looking at the Adapter, I see:

    public override View GetView(int position, View convertView, ViewGroup parent)
    {
        var element = ElementAtIndex(position);
        if (element == null)
        {
            element = ElementAtIndex(position - 1);
            while (!(element is Section))
                element = element.Parent;
            return ((Section)element).GetFooterView(_context, convertView, parent);
        }
        return element.GetView(_context, convertView, parent);
    }

This suggests FooterView is 'hacked in' a bit - but HeaderView isn't :/