Question

I am working on a project right now and we are using the MvvmCross framework. The project should be done in february. We were wondering if we should wait for AutoView as a cross platform UI solution, or would february be to soon?

The problem we have right now is that we want to be able to build a BindableListView dynamically. Then every item in the list could have a different layout and its set of views, for example when I have a list of list of strings and integers in any order, the BindableListView would show a TextView for every string and a numberpicker for every int.

Something like this:

public ElementDescription DefaultView()
{
    var auto = new RootAuto(caption: "TestRootElement")
    {
        new SectionAuto(header: "Test Info")
            {
                foreach(item s in list)
                {
                    if(s.GetType() == typeof(string) )
                        new StringAuto();
                    if(s.GetType() == typeof(int)
                        new IntAuto();
                }              
            };

        return auto.ToElementDescription();
    }
}

Would this even be possible with AutoView? Or should we look for a different solution?

Answer 1

Simple answer – If it’s for a real project with a pressing deadline… probably not.

---

Longer answers…

When will autoview be available?

AutoViews will be available for Droid only ‘this week’ – this includes automatic options for dialog, menu and list screens.

For Touch, I’d expect AutoViews to arrive within 2-3 weeks – but this work may impact back onto the Droid work in some ways – e.g. some classes and methods may need to be tweaked.

For WP and for WinRT, the timeline is currently less clear. There are a couple of people working on WP.Dialog ports and the timeline for these is unclear…

When will the entire AutoView package be available? When will the API be stable? How many samples will be around? When will documentation be supplied? I don’t know. Hopefully late December, early January – but there are external factors to consider here (including some MvvmCross additions that will happen when async/await arrive for MonoTouch/Droid).

---

What will autoviews be used for?

My main focus for autoviews is to allow rapid cross platform development – so they will provide a quick way to get UIs up and running on 4 platforms.

These UIs will be skinnable – e.g. using UIAppearance on MonoTouch and using custom axml on MonoDroid. These UIs will also be extensible and override-able – there will be no lock-in to the AutoView approach.

It may well be that these UIs are ‘good enough’ to ship for many customers – e.g. apps like TweetStation (and plenty more besides) have shown how MonoTouch.Dialog can produce really very nice finished apps, and I hope for the same from AutoViews.

However, AutoView UIs will never be as powerful or flexible as full custom UIs on each platform – so many apps will also not want to use AutoViews – or will want to override significant parts of them.

---

Can I use AutoViews today?

Yes.

But:

• only on Droid
• you need to be happy using PCLs for development (AutoViews only exist in the vNextDialog branch right now)
• you need to expect some namespace, class and method changes in the coming weeks (e.g. currently we are using MonoDroid.Dialog in a FooBar namespace)
• you probably want to fork the repository to isolate yourself from those changes.
• there are also some small performance penalties for using AutoViews – the UIs are built using reflection which is always slower than direct code (this isn’t a huge penalty, but if you are a low level developer who likes to make your code really fly, then you will prefer to steer clear of reflection).