Wednesday, October 31, 2012

How to ask questions about MvvmCross?

If you've got questions... then that's good.

I love answering questions about Mvx and hearing about what users want.

Take a look at all the information that's already available - http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html

So please feel free to ask questions by:

1. You can post them on StackOverflow - http://stackoverflow.com/questions/tagged/mvvmcross - please think about your question and provide as much detail as you can - I generally spend about 10 minutes to write a good answer so please also spend 10 minutes writing a good question.

For all questions, please search first - if there are any similar problems/questions then consider referencing them in your question.

For complicated questions, please consider writing a separate small test app which focusses on the problem area, rather than posting all your code - no-one has time to read all your code :)

If you find you have followup questions... then please do not update your question... and please do not ask new questions in comments - open a new question instead :)

2. You can post them on http://forums.xamarin.com - but again the more relevant detail you can provide the better - consider adding a gist for code - http://gist.github.com/

3. If you think it is a bug or a new feature then you can open a new issue on https://github.com/slodge/MvvmCross/issues/new - ideally include some sample code that I can build and run - if you have a test application please put it in a repo somewhere. If I have to make a test app myself for each and every issue then I'll be slower to answer...

4. You can come along to http://jabbr.net/#/rooms/mvvmcross but please don't ask too many questions there - it's not a great place to ask questions to look at code or to share things really - and it's not very searchable so it's hard for answers to benefit others...

Looking forwards to hearing from you all :)

Stuart

Tuesday, October 30, 2012

Testing ViewModels in MvvmCross

One question I've been meaning to answer for a while is how I setup my unit tests so that I can test viewmodel behaviour.

This is actually very simple to do. There are just a couple of things to put in place to cope with the singleton nature of MvvmCross IoC

Also, please note that if you want to test on MonoTouch then because there are dynamic code restrictions, then you cannot use Dynamic Mocks (like Moq)

*1. First in the test setup, I clear the IoC system using code like:

    private IMvxServiceProviderRegistry _ioc;

    [SetUp]
    public void SetUp()
    {
        // fake set up of the IoC
        MvxOpenNetCfContainer.ClearAllSingletons();
        MvxOpenNetCfServiceProviderSetup.Initialize();
        _ioc = MvxServiceProvider.Instance;
        _ioc.RegisterServiceInstance(new MvxDebugTrace());
        MvxTrace.Initialize();
    }

*2. Then to test general navigation I use a couple of Mocks like:

public class MockMvxViewDispatcherProvider : IMvxViewDispatcherProvider
{
    #region IMvxViewDispatcherProvider implementation

    public IMvxViewDispatcher Dispatcher { get; set; }

    #endregion
}

public class MockMvxViewDispatcher : IMvxViewDispatcher
{
    public List CloseRequests = new List();
    public List NavigateRequests = new List();

    public MockMvxViewDispatcher()
    {
    }

    #region IMvxViewDispatcher implementation

    public bool RequestNavigate(MvxShowViewModelRequest request)
    {
        NavigateRequests.Add(request);
        return true;
    }

    public bool RequestClose(IMvxViewModel whichViewModel)
    {
        CloseRequests.Add(whichViewModel);
        return true;
    }

    public bool RequestRemoveBackStep()
    {
        throw new NotImplementedException();
    }

    #endregion

    #region IMvxMainThreadDispatcher implementation

    public bool RequestMainThreadAction(Action action)
    {
        action();
        return true;
    }

    #endregion
}

The main thing these Mocks appear to do is to catch and store the navigation requests.

IMPORTANT NOTE: however, please do note the IMvxMainThreadDispatcher code - this service is essential to much of the operation of MvvmCross - lots of things in MvvmCross rely on this service being available because they need to get their execution across to some "UI thread" - e.g. PropertyChanged will silently fail to fire if the service is missing!

*3. To then test navigation I use tests like:

    [Test]
    public void ExecutingTheLoginCommandNavigatesToTheLoginViewModel()
    {
        var mockNavigation = new MockMvxViewDispatcher();
        var mockNavigationProvider = new MockMvxViewDispatcherProvider();
        mockNavigationProvider.Dispatcher = mockNavigation;
        _ioc.RegisterServiceInstance(mockNavigationProvider);

        var homeViewModel = new HomeViewModel();
        homeViewModel.LoginCommand.Execute(null);

        Assert.That(mockNavigation.NavigateRequests.Count == 1);
        Assert.That(mockNavigation.NavigateRequests.First().ViewModelType == typeof(LoginViewModel));
    }

    [Test]
    public void ExecutingTheCloseCommandClosesTheViewModel()
    {
        var mockNavigation = new MockMvxViewDispatcher();
        var mockNavigationProvider = new MockMvxViewDispatcherProvider();
        mockNavigationProvider.Dispatcher = mockNavigation;
        _ioc.RegisterServiceInstance(mockNavigationProvider);

        var loginViewModel = new LoginViewModel();
        loginViewModel.CloseCommand.Execute(null);

        Assert.That(mockNavigation.CloseRequests.Count == 1);
        Assert.That(mockNavigation.CloseRequests.First() == viewModel);
    }

*4. And to test ViewModel property changes I just use simple code like:

    [Test]
    public void ExecutingTheAddCommandIncrementsTheCounter()
    {
        var mockNavigation = new MockMvxViewDispatcher();
        var mockNavigationProvider = new MockMvxViewDispatcherProvider();
        mockNavigationProvider.Dispatcher = mockNavigation;
        _ioc.RegisterServiceInstance(mockNavigationProvider);

        var tipViewModel = new TipViewModel();
        Assert.That(tipViewModel.Counter == 0);
        var notifications = new List();
        tipViewModel.PropertyChanged += (s, e) =>
            {
                notifications.Add(e.PropertyName);
            };

        tipViewModel.CloseCommand.Execute(null);

        Assert.That(mockNavigation.CloseRequests.Count == 0);
        Assert.That(mockNavigation.NavigateRequests.Count == 0);
        Assert.That(notifications.Count == 1);
        Assert.That(notifications[0] == "Counter");
        Assert.That(tipViewModel.Counter == 1);
    }

*5. And that's it... these tests work cross-platform - including in the lovely NUnit tool from Xamarin for MonoTouch

Possible solutions for WP8 SDK Emulator issues - WP8 Hyper-V emulator cannot see the wireless network adapter

Now the NDA is over...

I had a problem with windows phone 8 sdk accessing the wireless network on my host laptop.

Some solutions/questions I saw reported when trying to debug this were:

  • Plugin an Ethernet cable - that worked for me!
  • Problem solved! Hyper-V uses same MAC address for guest VMs (virtual machine) and Host. If the router configured to give the host always same ip address it will conflict with the emulator. Solution - on the router remove the host from known PCs and let it give you some new ip address (not fixed). After you start the emulator it will get the correct ip address from router. Router will show you two PCs (host and vm) with the same MAC, but different ip addresses.

  • I encountered a problem with installing Hyper-V on a german installation of Windows 8 but have found people having the same issue with other localized versions. After setting the checkbox to install Hyper-V and clicking ok it simply did not install. I had to change my regional settings to english, install it and switch them back to german for everything to work.

    Maybe the SDK simply triggered the installation correctly or the recent big Windows 8 patch resolved the problem. Although it might be that you had different problems with installing Hyper-V.

  • It is possible that the emulator's virtual machine is corrupted.

    1. Close Visual Studio. Launch Hyper-V Manager.

    2. In the Virtual Machines list, stop and then delete any virtual machines currently running

    3. Try your app again. A new emulator VM instance should start.

    If that doesn't fix it, click on the running VM instance in Hyper-V Manager. In the Actions column for your Emulator instance, click on Settings, and drill down into the Network adapter hardware. See if a Virtual Switch is selected for the network adapter etc.

  • Hi everyone, We have some steps to run the emulator:

You must have Windows 8 Pro (Ultimate or Enterprise).
Enable Hyper-V on Control panel.
Restart your computer.
Install Windows Phone 8 SDK.
Restart your computer, again.
Run the Emulator! Takes very very long time if you don't do the step 5.
Happy coding!

Origo Foci-Eb 2012 - an example mvvmcross app from earlier this year

This App launched in Hungary this year ahead of the European Football Championships.

It was built on MonoDroid, MonoTouch, WP7 and MvvmCross

It shows really nicely how to show the same ViewModel data in a nice Native UI style.

I couldn't find the iOS screenshots, but some Droid and WP7 goodness is below:

Android  - https://play.google.com/store/apps/details?id=OrigoEB.Main



WindowsPhone http://www.windowsphoneapplist.com/en/Origo_FociEb_2012-a116571.html



The developer was - I believe he or one of his team may also have something to do with the excellent sample at https://github.com/Zoldeper/Blooor

MonoTouch, MonoDroid and MvvmCross at Build Windows 2012 in Seattle #BldWin

From http://channel9.msdn.com/Events/Build/2012/3-004:

Learn how to create an app with versions for the Windows Store, Windows Phone, and other platforms, using the new Portable Class Libraries support in Visual Studio 2012 to share code between the different versions of the app. We will see how the Model-View-ViewModel pattern (MVVM) is ideally suited to sharing code between platforms since it encourages a clean separation between the app logic, which can be shared, and the UI, which is platform-specific. We'll see how to access non-portable functionality from portable code by creating a portable abstraction with platform-specific implementations. We will see several real-world demo apps, and touch on more advanced concepts such as navigation, inversion of control, and synchronizing data across multiple clients with Windows Azure Service Bus. To maximize your benefit from this session, having some prior experience with XAML-based apps and the MVVM pattern is recommended.

I don't know what the content will be...

But if it's anything like this blog post - http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx - then it should be very useful :)

Sunday, October 28, 2012

A temporary solution for the Profile1 only bug in MonoDevelop MonoTouch PCL support

Update: install the patch - http://slodge.blogspot.co.uk/2013/02/a-patched-monodevelop-for-pcls.html

Thanks especially to "Jonathan Peppers"...

There is a solution to the problem that MonoDevelop can only build Profile1 for MonoTouch PCL libraries.

The solution is to use Conditional MSBuild attributes.

So... replace:

    <TargetFrameworkProfile>Profile104</TargetFrameworkProfile>
with:
    <TargetFrameworkProfile Condition="'$(OS)' != 'Windows_NT'">Profile1</TargetFrameworkProfile>      <TargetFrameworkProfile Condition="'$(OS)' == 'Windows_NT'">Profile104</TargetFrameworkProfile>
This can be done using Replace In Files :)

Afterwards it seems to work perfectly in both Visual Studio and in MonoDevelop :)

Stuart

Saturday, October 27, 2012

Mvvm MonoTouch back up and running :)

I've got a new Mac Air

Bought it through the refurb store - feels like new :)

The good news is that with just a few additions/changes I can build and run the Mvvm Monotouch solution in vNext in https://github.com/slodge/mvvmcross

The small hacks are:

Edit the file /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild/Microsoft/Portable/v4.0/Microsoft.Portable.CSharp.targets, finding the PropertyGroup that sets

  <TargetFrameworkIdentifier>MonoTouch</TargetFrameworkIdentifier>  

And to it, adding the lines:

  <CscToolExe>smcs</CscToolExe>  <CscToolPath>/Developer/MonoTouch/usr/bin</CscToolPath>

Note that doing this needs R+W permission on that file.

----

Then after that, you need to convert all the portable CSProj files so that they use Profile1, not Profile104 (but back on the PC you will need Profile104 again)

To do this - replace in files, choose *.csproj, and choose to replace ">Profile104<" with ">Profile1<"

----

So now back to work... :)

Friday, October 26, 2012

Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information

To fix this error.... first find the Assembly which is causing the problem!

Useful code from http://stackoverflow.com/questions/1091853/unable-to-load-one-or-more-of-the-requested-types-retrieve-the-loaderexceptions
  
using System.IO;
using System.Reflection;

try
{
    //The code that causes the error goes here.
}
catch (ReflectionTypeLoadException ex)
{
    StringBuilder sb = new StringBuilder();
    foreach (Exception exSub in ex.LoaderExceptions)
    {
        sb.AppendLine(exSub.Message);
        if (exSub is FileNotFoundException)
        {
            FileNotFoundException exFileNotFound = exSub as FileNotFoundException;
            if(!string.IsNullOrEmpty(exFileNotFound.FusionLog))
            {
                sb.AppendLine("Fusion Log:");
                sb.AppendLine(exFileNotFound.FusionLog);
            }
        }
        sb.AppendLine();
    }
    string errorMessage = sb.ToString();
    //Display or log the error based on your application.
}

MvvmCross - experiences, hindsight, limitations?

I get asked a lot about the benefits and problems of mvvmcross... sometimes it's phrased just like 'mvvmcross - wtf?'

The answer is always to point them at this question on StackOverflow -

MvvmCross experiences, hindsight, limitations?

Wednesday, October 24, 2012

Going outside of mvvm sometimes - live video preview in mvvmcross/monodroid

An interesting topic came up yesterday on StackOverflow.

The question was about video views and how to get native objects working inside portable code.

The answe I gave was a bit cowardly... It was to do most of the code natively (using xamarin mobile helpers) and to then bind to the view model at quite a simple level.

The poster took my advice and has now posted their code.... https://gist.github.com/3945799

There are definitely still places where more could be abstracted... And I'm still thinking about whether my original advice was correct...

Still thinking...

Tuesday, October 23, 2012

More progress on the Portable UI prototype

I now have a working sample on Droid with JSON loaded for both Menus and for Dialogs.

These files are automatically picked up using Conventions - no configuration required.

Next steps...
  • tidy it up a bit (thank you Resharper!)
  • add a list/listitem format,
  • try it out on Touch, WP and WinRT

Sunday, October 21, 2012

About me and my company - Stuart Lodge, Cirrious Ltd

Just a quick overview of some of the lovely things I work on:



https://speakerdeck.com/u/cirrious/p/cirrious-ltd

Saturday, October 20, 2012

How the JSON Android.Dialog project works - and how WP.Dialog might work

Here's a very rough description of what I'm thinking - https://speakerdeck.com/u/cirrious/p/cross-plat ...

WP.Dialog is (I think) just the 'Form' part of that - just like Android.Dialog and MonoTouch.Dialog - although later it might grow in scope to the entire project - baby steps first:)

Also to be clear... I think WP.Dialog can exist and run without any dependency on MvvmCross - I don't see why it couldn't be useful for code-behind projects, for MvvmLight, etc

The projects
There are 5 projects:

  • Core.Dialog - a PCL containing:
    • Descriptions - the structs which describe a UI
    • Elements - the basic interfaces which UI components have to obey
    • Builder - the abstract code which turns Descriptions into Elements
  • Android
    • Android.Dialog - an Android Library containing:
        • Attributes - not currently used but provide a *very* nice way to turn C# models into UIs - see MonoTouch.Dialog for more
        • Builder - inherits from Core.Dialog.Builder - provides the *very small* Android specific building part
          • Elements - the default elements... the ones to start with are:
            • RootElement (which is a mess because it is a RootElement and also has RadioGroup functionality built in)
            • StringElement - displays a Caption and a Value
            • ValueElement - displays a Caption and an Editable Value
              • EntryElement
              • FloatElement
              • CheckboxElement
            • DO NOT START with RadioElement, WebElement, HtmlElement, etc - it's confusing!
        • Enums - mainly ignored... most seem to be there for MT.Dialog API compatability
        • Root-Level classes - DialogListView and DialogAdapter - together these 2 things provide the 'UI Control'
      • DialogSampleApp - the Android Demo project
        • MainDialogActivity - is the only activity that has been updated to the new JSON
  • Touch - ****nowhere near working****
    • Cirrious.MvvmCross.Dialog.Touch - my branch of MonoTouch.Dialog
    • Sample - the MonoTouch Sample

Within this layout... I guess WP should work in a new folder WindowsPhone and have two projects - a Dialog and a Sample :)

Naming: I'd like to put these projects in some namespace - for Mvx I used Cirrious (which is my company name) but that's mainly because of the way the project started - it was a company job! No idea what namespace to use, but I'd like to use Something.Dialog.Core rather than just Dialog.Core...


The MainDialogActivity code
For understanding Android.Dialog:
  • a good place to start might be MainDialogActivity.
  • This contains:
    • a big block of JSON
    • some code at the start of OnCreate to load the JSON
    • a big block of commented out C# which is equivalent to the JSON
Putting the big block of comment out code side-by-side with the JSON should help work out what is happening - and maybe looking at Dialog.Core.Descriptions will help with working out what the structure of the API is.

A quick walkthrough the code at the start of OnCreate:
            DroidResources.Initialise(typeof(Resource.Layout));
            var parser = new DroidElementBuilder();
 
            var setter = new ExampleActionPropertySetter();
            setter.Actions["ShowDialogActivity"] = (sender, args) => StartNew();
            setter.Actions["ShowDialogListViewActivity"] = (sender, args) => ClickList();
            setter.Actions["ElementTest"] = (sender, args) => ClickElementTest();
            parser.CustomPropertySetters["Action"] = setter;
            var description = Newtonsoft.Json.JsonConvert.DeserializeObject<ElementDescription>(JsonText);
            Root = parser.Build(description) as RootElement;
Breaking this down:

            DroidResources.Initialise(typeof(Resource.Layout));

The first line initialise the DroidResources - what this does is it tells the DroidResources where to look for numeric Android ResourceIds - e.g. when you load a StringElement then the framework might look for some AXML called dialog_string_layout (or similar) - these resources are in the resources folder.

            var parser = new DroidElementBuilder();
This creates a builder (not a parser - sorry!).

The Builder stores a lookup list of string names to Element Types

There is a default parameter to DroidElementBuilder which tells the Builder to reflect the Android.Dialog namespace and to look for the default set of Element Types.

Users can also register custom Element Types if they want to - so if you invent a RuneElement, then you can add it.

            var setter = new ExampleActionPropertySetter();
            setter.Actions["ShowDialogActivity"] = (sender, args) => StartNew();
            setter.Actions["ShowDialogListViewActivity"] = (sender, args) => ClickList();
            setter.Actions["ElementTest"] = (sender, args) => ClickElementTest();
            parser.CustomPropertySetters["Action"] = setter;

This block of code sets up a custom property setter for 'Action'. This means that if ever a property is marked in the Json with a value "@Action:foobar" then this property and foobar will be passed to the custom setter.

In a 'coming soon' step I expect to add an MvxBind custom property setter...

            var description = Newtonsoft.Json.JsonConvert.DeserializeObject<ElementDescription>(JsonText);

This uses PCL JSON.Net to deserialize the ElementDescription JSON. Note that the framework is decoupled from JSON - so users could use XML, ProtoBuf, C#, etc instead!


            Root = parser.Build(description) as RootElement;
Finally this line passes the description to the builder :)


How an Android Element is built
If some JSON comes in like:

                {
                    'Key':'String',
                    'Properties':{
                        'Caption':'Click for EntryElement Test',
                        'Click':'@Action:ElementTest'
                    }
                }
then this maps to an ElementDescription.

The builder uses this:
  • The Key 'String' is mapped to 'StringElement' - so it uses Reflection to call the parameterless constructor of StringElement (or the constructor with default parameters)
  • The builder then iterates the Properties 
    • uses reflection to set the Caption property on the StringElement to 'Click for EntryElement Test'
    • notices the '@Action:' prefix - so passes the Click PropertyInfo and 'ElementTest' to the custom property setter
That's it! You can set as many properties as there are available - it's up to the StringElement to turn those properties into something on the display.

Note that property values can be strings, numerics or booleans - anything else has to go through a special handler (e.g. a string lookup or a JSON serialised object)

Note that there is no real data binding right now - but that will come with '@MvxBind;' :)

Note that later there may be some chances to add platform specific properties - e.g. something like:

                    'Properties':{
                        'Caption':'Click for EntryElement Test',
                        'Click':'@Action:ElementTest',
                        '@Droid:WarpSpeed':4,
                        '@WindowsPhone:Pinned':false,
                    }


How an entire Dialog is displayed
In Android and in Touch, the Dialog is displayed using a ListView

The reason for this is because it allows UI virtualisation... and also because MonoTouch doesn't really have a StackPanel!

This use of a ListView makes the UI a bit more complicated than is really needed... e.g. for small forms it would actually be a lot easier to not have any cell reuse.

For WindowsPhone, it might be easier to just use a StackPanel with fixed members - but you could use a List if you wanted to....

In Android, the basic approach is:

- the UI View (Activity) is a List (including Groupings)
- the UI View gets help from an Adapter
- the Adapter stores the list of Elements
- when it comes to time to render the UI, then the Adapter's GetView gets called for every visible 'index'
- the Adapter passes the GetView call through to the GetView on the individual Element - this is passed through to GetViewImpl
- currently the GetViewImpl passes everything through eventually to DroidResources - which loads 'axml' for the element.
- calls like UpdateDetailDisplay and UpdateCaptionDisplay are used in the Element to actually fill in values in the Element

Note that because it uses a list, then there is an opportunity for cell reuse. In Mt.Dialog this works quite well. In Android.Dialog I think it's currently broken - but I will fix it.

So for WP.Dialog
I would expect for WP:
  • the same JSON will be used
  • the JSON will be parsed by JSON.Net
  • a WindowsPhoneBuilder will be used
  • this WindowsPhoneBuilder will (by default) know about a set of WindowsPhone Elements - which it will construct using reflection
  • these Elements will contain some C# and will somehow map to XAML...
  • the XAML will be parented either in a StackPanel (inside a ScrollViewer) or inside a ListView
  • if you use a ListView it's just a bit more complicated to route the bindings and to reuse controls (it's a standard 'ListItemSelector' type thing)
  • it would be really nice if the XAML is very easily styleable - like custom controls are
To get started...
  • maybe just try some JSON with some StringElements - each has a Caption and Value
  • then try adding an EntryElement - Caption and Value
  • then try adding a CheckboxElement - Caption and Boolean Value
The idea would be to creative native looking form UIs from the same JSON:

And then (if we're lucky) people can add platform specific styling to those UIs.

Cross Platform Views for MvvmCross... ideas...

This is the sort of thing I'm currently thinking about....

Friday, October 19, 2012

Update on the Portable Dialog JSON UI idea

Just an update on this - I just (this morning) have this sample below working.
sample
Full image: http://i.imgur.com/XJHpD.png

Obviously there is still a need for:
  • event handling - using ICommand or Delegates somehow
  • some elements need tweaking - especially custom Views and Images
  • integration with binding (for MvvmCross)
However, I think the basic idea should work pretty well across Android.Dialog and also the mvvmcross fork of MonoTouch.Dialog.

And I do intend to add a WinRT.Dialog and a WindowsPhone.Dialog too...

If anyone's interested, then post here or on https://github.com/slodge/Android.Dialog/issues/4

{
    'Key':'Root',
    'Properties':{
        'Caption':'TestRootElement'
    },
    'Sections':[
        {
            'Elements':[
                {
                    'Key':'String',
                    'Properties':{
                        'Caption':'Label',
                        'Value':'Only Element in a Blank Section'
                    }
                }
            ]
        },
        {
            'Properties':{
                'Header':'Test Header',
                'Footer':'Test Footer'
            },
            'Elements':[
                {
                    'Key':'Button',
                    'Properties':{
                        'Caption':'DialogActivity - needs ICommand'
                    }
                },
                {
                    'Key':'String',
                    'Properties':{
                        'Caption':'DialogListViewActivity - needs ICommand',
                        'LayoutName':'dialog_labelfieldright'
                    }
                },
                {
                    'Key':'Boolean',
                    'Properties':{
                        'Caption':'Push my button',
                        'Value':true
                    }
                },
                {
                    'Key':'Boolean',
                    'Properties':{
                        'Caption':'Push this too',
                        'Value':false
                    }
                },
                {
                    'Key':'String',
                    'Properties':{
                        'Caption':'Click for EntryElement Test - needs ICommand'
                    }
                }
            ]
        },
        {
            'Properties':{
                'Header':'Part II'
            },
            'Elements':[
                {
                    'Key':'String',
                    'Properties':{
                        'Caption':'This is the String Element',
                        'Value':'This is it\'s value'
                    }
                },
                {
                    'Key':'Checkbox',
                    'Properties':{
                        'Caption':'Check this out',
                        'Value':true
                    }
                },
                {
                    'Key':'Entry',
                    'Properties':{
                        'Caption':'Username',
                        'Value':'',
                        'Hint':'Enter Login'
                    }
                },
                {
                    'Key':'Entry',
                    'Properties':{
                        'Caption':'Password',
                        'Value':'',
                        'Hint':'Enter Password',
                        'Password':true
                    }
                }
            ]
        },
        {
            'HeaderElement': {
                'Key':'String',
                'Properties':{
                    'Caption':'Can Populate be done?',
                    'Value':'Need to look at how ViewElement works...'
                }
            },
            'Properties':{
                'Header':'Group'
            },
            'Elements':[
                {
                    'Key':'Root',
                    'Properties':{
                        'Caption':'Radio Group - needs work!'
                    }
                }
            ]
        }
    ]
}

Thursday, October 18, 2012

Starting to play with the idea of a cross platform UI framework

Hi All

I've started playing with the idea of doing a cross platform UI framework - at least for those UIs that can be done by MonoTouch.Dialog type displays.

See the idea in very raw form at: https://github.com/slodge/Android.Dialog/issues/4

Is this of interest... if it is then comment here or on GitHub

Stuart

Wednesday, October 17, 2012

Creating custom views is easy to do...

This answer came from a question about creating custom view behaviour inside a list in MvvmCross for MonoDroid - http://stackoverflow.com/questions/12934654/how-to-create-views-actions-listener-for-mvxitemtemplate


---

Creating custom views is easy to do...

namespace Angevelle.App1.UI.Droid.Controls
{
    public class MyText : EditText
    {
        public MyText(Context context, IAttributeSet attrs)
            : base(context, attrs)
        {
            this.EditorAction += OnEditorAction;
        }

        private void OnEditorAction(object sender, EditorActionEventArgs editorActionEventArgs)
        {
            if (editorActionEventArgs.ActionId == ImeAction.Done)
            {
                // this code not tested - but something like this should work
                var imm = (InputMethodManager)Context.GetSystemService(Context.InputMethodService);
                imm.HideSoftInputFromWindow(WindowToken, 0);
            }
        }
    }
}

Then you can use that View in your AXML just as you do Android or Mvx views:

<angevelle.app1.ui.droid.controls.MyText
         android:layout_height=....
     />

If you are finding angevelle.app1.ui.droid.controls too verbose, then you could shorten this using an abbreviation in setup.cs:

    protected override IDictionary ViewNamespaceAbbreviations
    {
        get
        {
            var abbreviations = base.ViewNamespaceAbbreviations;
            abbreviations["Abv"] = "angevelle.app1.ui.droid.controls";
            return abbreviations;
        }
    }
then you can just use:

<Abv.MyText
android:layout_height=.... />

Build a new plugin for mvvmcrosss

Update: This advice below is for vNext. For more up to date advice, see: http://stackoverflow.com/questions/16788164/custom-plugin-in-mvvmcross

-----

 1. Create a central shared plugin

This would be Portable Class library - say MyCompany.MvvmCross.Plugins.Mega
Within that central shared PCL, you would put whatever portable code was available - often this might only be a few service Interface definitions - e.g.

public interface IAlphaService { ... }

and

public interface IPageService { ... }

You'd then add the PluginManager for that plugin which would just add the boiler-plate of:

public class PluginLoader
    : IMvxPluginLoader

    , IMvxServiceConsumer<IMvxPluginManager>

{
    public static readonly PluginLoader Instance = new PluginLoader();


    #region Implementation of IMvxPluginLoader

    public void EnsureLoaded()

    {
        var manager = this.GetService<IMvxPluginManager>();

        manager.EnsureLoaded<PluginLoader>();
    }


    #endregion
}

2. Create the specific plugin implementations

For each platform, you would then implement the plugin - e.g. you might implement MyCompany.MvvmCross.Plugins.Mega.WindowsPhone and MyCompany .MvvmCross.Plugins.Mega.Droid

Within each of these you will implement the native classes which provide the services:
public class MyAlphaService : IAlphaService { ... } 

and
public class MyPageService : IPageService { ... }

Finally each plugin would then provide the boilerplate plugin implementation:

public class Plugin
    : IMvxPlugin

    , IMvxServiceProducer
{
    #region Implementation of IMvxPlugin


    public void Load()
    {

        // alpha registered as a singleton
        this.RegisterServiceInstance<IAlphaService>(new MyAlphaService());

        // page registered as a type
        this.RegisterServiceType<IPageService, MyPageService>();

    }

    #endregion
}

3. Instantiation of plugins

Each UI client will have to initialise the plugins.
This is done by the end UI client adding library references to:
  • the shared core plugin
  • the appropriate plugin implementation

3.1 WinRT, WindowsPhone and MonoTouch

Then, for WinRT, WindowsPhone and MonoTouch clients, you also need to provide a Loader accessor in setup.cs - like:
    protected override void AddPluginsLoaders(Cirrious.MvvmCross.Platform.MvxLoaderPluginRegistry loaders)

    {
        loaders.AddConventionalPlugin<MyCompany.MvvmCross.Plugins.Mega.WindowsPhone.Plugin>();

        base.AddPluginsLoaders(loaders);
    }

Note that Convention is used here - so it's important that MyCompany.MvvmCross.Plugins.Mega.WindowsPhone.Plugin implements the WindowsPhone plugin for MyCompany.MvvmCross.Plugins.Mega.PluginLoader

3.2 MonoDroid

For MonoDroid clients, you don't need to add this setup step - because MonoDroid has less Assembly.Load restrictions than the other platforms - and ao can load the plugins from file. But for this to work, it's important that the assembly names match - if the PluginLoader is AlphaPage.MvvmCross.Plugins.Mega.PluginLoader then the conventions will try to load the plugin from MyCompany.MvvmCross.Plugins.Mega.Droid.dll

4. Use of plugin services

After this setup, then applications should finally be able to access the plugins by:
  • adding a reference the Shared core portable library
  • at some time calling MyCompany.MvvmCross.Plugins.Mega.PluginLoader.Instance.EnsureLoaded()
  • then accessing the individual services using this.GetService() or this.GetService()

5. Pure portable plugins

Some plugins can be 'pure portable'

In this case they don't need any specialization for each platform, and no step 3 is required.

For an example of this, see the Json implementation - https://github.com/slodge/MvvmCross/tree/vnext/Cirrious/Plugins/Json

How to bind an Android ImageView to an image loaded from Monodroid Assets

From StackOverflow 

Quick answer:

  • if your Android image file is stored in assets/images/i1.png
  • then make sure it is marked as an AndroidAsset
  • then your path needs to be images/i1.png

Longer answer:

Ideally your ViewModel should be platform independent and not know about View concerns.

So your ViewModel might perhaps expose a property like:

 private GameState _state;
 
public GameState State
 
{
     get
{ return _state; }
     set
{ _state = value; RaisePropertyChanged(() => State); }
 
}

where GameState is an enumeration like:

 public enum GameState
 
{
     
Stopped,
     
Running,
     
Paused,
     
GameOver
 
}

you might then have images representing these states in an assets structure like:

/assets/gamestates/stopped.png
/assets/gamestates/running.png
/assets/gamestates/paused.png
/assets/gamestates/gameover.png

where each of those files is marked with BuildAction of AndroidAsset.

To then display the correct image in the UI, you would need a value converter like:

public class GameStateConverter
   
: MvxBaseValueConverter
{
   
public override object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
   
{
       
return string.Format("gamestates/{0}.png", ((GameState)value).ToString().ToLower());
   
}
}

mapped in using a Converters wrapper like:

public class Converters
{
   
public readonly GameStateConverter GameState = new GameStateConverter();
}

which is configured in setup.cs using:

    protected override IEnumerable<Type> ValueConverterHolders
   
{
        get
{ return new[] { typeof(Converters) }; }
   
}

With this in place, then your axml binding statement would be:

    {'AssetImagePath':{'Path':'State', 'Converter':'GameState'}}

For an alternative approach using resources instead of assets, see MvxButtonIconBinding in Іssue with binding to GridLayout to Android

Tuesday, October 16, 2012

Building mvvmcross projects in visual studio 2012

I've recently been building almost all my vNext mvvmcross projects in all of "Visual Studio 2010", "Visual Studio 2012" and in MonoDevelop.

My basic setup for this has been the same one described in: http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html
  • I've installed VS, the Portable Class Library VS2010 extensions, VS2012, MonoDroid and VSMonoTouch
  • I've then altered the registered Portable Library platforms just a little in order for Droid and Touch to both work under the magical Profile 104
All in all, the setup works reasonably well - well enough indeed that I decided to switch over to vNext as the default GitHub branch now.

However, working this way, I do admit I've experienced several small problems, and I thought I might list them here in case they help others:
  1. VSMonoTouch doesn't yet work in VS2012 - so there's no iOS support in VS2012 yet. There are some people who have got this working over on GitHub, but I've held off implementing anything in case Xamarin pull some magic out of the hat during this week's MonkeySpace conference.
  2. MonoDevelop refuses to open any solution that Visual Studio 2012 has opened - this is due to a Version number - 12 instead of 11 - at the start of the .sln file - it takes seconds to fix in NotePad++, but it is annoying
  3. There are some issues building MonoDroid portable projects in VS2012 sometimes - sometimes it takes 2 builds rather than 1 - no idea what this is yet - it feels like its somehow not quite hooking up the dependencies correctly between PCL and MonoDroid. I've not seen this problem at all in VS2010.
  4. There are some issues sometimes on putting breakpoints in the PCL code - again I've not identified what this is completely yet - and I have a feeling it may be a more general MonoDroid bug, and nothing to do with VS2012.
  5. I have seen some TargetFrameworkAttribute errors in VSMonoTouch projects - see http://slodge.blogspot.co.uk/2012/09/the-type-or-namespace-name.html for my hacky solution.

However.... overall, that's it - I'm up and running and Resharper is working too :)